使用HTTP GET，PUT，DELETE，POST，HEAD有什么实际好处？为什么不关注他们的行为优势（安全性和幂等性），忘记他们的名字，并根据我们想要的行为使用GET，PUT或POST？
为什么我们不应该只使用GET，PUT和POST（并删除HEAD，DELETE）？
答案 0 :(得分：22)
[REST] [1]方法使用POST，GET，PUT和DELETE来实现Web资源的CRUD规则。将对象暴露给Web上的请求是一种简单而整洁的方法。它是没有开销的Web服务。
只是为了澄清语义差异。每个操作都有很大的不同。关键是要有一个很好的HTTP方法，它们具有清晰，明确的含义。
POST创建新对象。 URI没有密钥;它接受定义对象的消息体。 SQL插入。 [编辑虽然POST没有技术原因没有密钥，但REST人员强烈建议POST具有与CREATE不同的含义，它不应该有密钥。]
GET检索现有对象。 URI 可能有一个键，取决于您是在进行单例GET还是列出GET。 SQL选择
PUT更新现有对象。 URI有一个键;它接受更新对象的消息体。 SQL Update。
DELETE删除现有对象。 URI有一个键。 SQL删除。
您可以使用POST而不是PUT更新记录吗？并非没有引入一些含糊之处。动词应具有明确的效果。此外，POST URI没有密钥，PUT必须有密钥。
当我发布POST时，我预计会创建一个201。如果我不明白，那就错了。同样，当我PUT时，我期待200 OK。如果我不明白，那就错了。
我想你可以坚持一些不明确的地方，POST可以POST或PUT。 URI必须是不同的;相关的消息也可能不同。通常，REST人员从SQL中获取提示，其中INSERT和UPDATE是不同的动词。
如果记录不存在，您可以说UPDATE应该插入，如果记录存在则更新。但是，如果UPDATE意味着UPDATE并且更新失败意味着出错，则更简单。对INSERT的秘密回落使得操作模糊不清。
如果您没有构建RESTful接口，那么通常只使用GET和POST进行检索和创建/更新。当一个人在表单上单击提交时，通常会有URI差异或消息内容差异来区分POST和PUT。但是，它不是很干净，因为您的代码必须确定您是在POST = create case还是POST = update case。
答案 1 :(得分：13)
POST无法保证safety or idempotency。这是 PUT 和 DELETE 的一个原因 - PUT和DELETE都是幂等的（即1 + N个相同的请求与1个请求具有相同的最终结果）。
PUT用于设置给定URI的资源状态。当您向特定URI的资源发送 POST 请求时，该资源 不应被替换内容。最多应该追加。这就是为什么POST不是幂等的 - 在附加POSTS的情况下，每个请求都将添加到资源（例如，每次将新的消息发布到讨论论坛）。
DELETE用于确保从服务器中删除给定URI的资源。 POST 通常不应用于删除，但提交删除请求的情况除外。同样，在这种情况下，您要POST的资源的URI不应该是要删除的资源的URI。 POST到的任何资源都是一种资源，它接受POSTed数据附加到自身，添加到集合或以其他方式处理。
如果您关心的只是GET请求的标头，并且您不想在实际内容上浪费带宽，则使用HEAD。这很好。
答案 2 :(得分：5)
为什么我们需要的不仅仅是POST？它允许数据双向流动，那么为什么需要GET呢？答案与您的问题基本相同。通过标准化各种方法的基本期望，其他过程可以更好地知道该做什么。
例如，干预缓存代理可以更好地做正确的事情。
比如想想HEAD。如果代理服务器知道HEAD的含义，则它可以处理来自先前GET请求的结果，以便为HEAD请求提供正确的答案。并且它可以知道不应该缓存POST，PUT和DELETE。
答案 3 :(得分：3)
没有人发布我正在寻找的那种答案，所以我会尝试自己总结这些观点。
“RESTful Web服务”第8章“重载POST”部分写道：“如果你想完全没有PUT和DELETE，那么通过GET公开资源的安全操作以及通过重载POST公开所有其他操作完全是RESTful。这违反了我的面向资源的体系结构，但它符合REST限制较少的规则。“
简而言之，替换PUT / DELETE而使用POST会使API难以阅读，而PUT / DELETE调用不再是幂等的。
答案 4 :(得分：2)
总之：
幂等性
再补充一句话：
GET = safe + idempotent
PUT =幂等
DELETE = idempotent
POST =既不安全也不是幂等
'Idempotent'只是意味着你可以一遍又一遍地做到这一点，它总会做同样的事情。
您可以根据需要多次重新发出PUT（更新）或DELETE请求，并且每次都会产生相同的效果，但是所需的效果会修改资源，因此不会被视为“安全”。
POST请求应该为每个请求创建一个新资源，这意味着每次效果都不同。因此，POST不被认为是安全的或幂等的。
像GET和HEAD这样的方法只是读取操作，因此被认为是“安全的”以及幂等。
这实际上是一个非常重要的概念，因为它提供了一种标准/一致的方式来解释HTTP事务;这在安全上下文中特别有用。
答案 5 :(得分：1)
答案 6 :(得分：1)
HEAD对于确定给定服务器的时钟设置为什么非常有用（精确到1秒或网络往返时间，以较大者为准）。它也很适合从Slashdot获得Futurama的报价：
~$ curl -I slashdot.org HTTP/1.1 200 OK Date: Wed, 29 Oct 2008 05:35:13 GMT Server: Apache/1.3.41 (Unix) mod_perl/1.31-rc4 SLASH_LOG_DATA: shtml X-Powered-By: Slash 2.005001227 X-Fry: That's a chick show. I prefer programs of the genre: World's Blankiest Blank. Cache-Control: private Pragma: private Connection: close Content-Type: text/html; charset=iso-8859-1
对于cURL，-I是执行HEAD请求的选项。要获取给定服务器的当前日期和时间，请执行
curl -I $server | grep ^Date
答案 7 :(得分：0)
限制歧义，以便更好/更容易地重用我们简单的REST apis。
答案 8 :(得分：0)
你只能使用GET和POST，但是你会失去PUT和DELETE带来的一些精确性和清晰度。 POST是一个通配符操作，可能意味着什么。 PUT和DELETE的行为定义非常明确。 如果您考虑使用资源管理API，那么GET，PUT和DELETE可能会覆盖80％-90％的所需功能。如果你限制自己使用GET和POST，那么使用指定不当的POST访问你的api的40％-60％。
答案 9 :(得分：0)
使用GET和POST的Web应用程序允许用户创建，查看，修改和删除他们的数据，但是在最初为此目的创建的HTTP命令之上的层上执行此操作。 REST背后的一个想法是回归Web设计的初衷，即每个CRUD动词都有特定的HTTP操作。
此外，HEAD命令可用于改善（可能很大）文件下载的用户体验。您调用HEAD以查明响应的大小，然后调用GET以实际检索内容。
答案 10 :(得分：0)
有关说明性示例，请参阅以下link。它还提出了一种使用OPTIONS http方法的方法，这里还没有讨论过。
答案 11 :(得分：0)
像WebDAV这样的http扩展需要额外的功能。
答案 12 :(得分：-1)
早期的网络服务器大战可能会引发它。
在HTTP 1.0 written in 1996, there were only GET, HEAD, and POST。但正如您在Appendix D中所看到的，供应商开始添加他们自己的东西。因此，为了保持HTTP兼容，他们被迫制作HTTP 1.1 in 1999。
但是，HTTP / 1.0没有充分考虑 分层代理的影响，缓存，需要 持久连接或虚拟主机。此外，扩散 未完成实现的应用程序调用自己 “HTTP / 1.0”需要更改协议版本 两个通信应用程序，以确定彼此的真正能力。
该规范定义了称为“HTTP / 1.1”的协议。该协议按顺序包含比HTTP / 1.0更严格的要求 确保其功能的可靠实施。
答案 13 :(得分：-4)
GET，PUT，DELETE和POST是一个二年级学生认为网页可以简化为一些忠诚原则的时代的延续。
如今，大多数网页都是复合实体，它们包含部分或全部这些基本操作。例如，页面可以包含用于查看或更新客户信息的表单，这些表单可能跨越多个表格。
我通常在php中使用$ _REQUEST []，而不是真正关心信息是如何到达的。我会选择使用基于效率的GET或PUT方法，而不是基础（多个）范例。