为什么我们需要的不仅仅是HTTP GET，PUT，POST？

StackOverflow https://stackoverflow.com/questions/147187

  •  02-07-2019
  •  | 
  •  

题

使用HTTP GET，PUT，DELETE，POST，HEAD有什么实际好处？为什么不关注他们的行为优势（安全性和幂等性），忘记他们的名字，并根据我们想要的行为使用GET，PUT或POST？

为什么我们不应该只使用GET，PUT和POST（并删除HEAD，DELETE）？

有帮助吗？

解决方案

[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。

其他提示

POST 不保证安全性或幂等性。这是 PUT 和 DELETE ＆＃8212的一个原因; PUT和DELETE都是幂等的（即，1 + N个相同的请求具有与仅1个请求相同的最终结果）。

PUT 用于设置给定URI的资源状态。当您向特定URI的资源发送 POST 请求时，该资源 不应被替换内容。最多应该追加。这就是为什么POST不是幂等的＆＃8212;在附加POSTS的情况下，每个请求都将添加到资源（例如，每次将新的消息发布到讨论论坛）。

删除 用于确保从服务器中删除给定URI的资源。 POST 通常不应用于删除，但提交删除请求的情况除外。同样，在这种情况下，您要POST的资源的URI不应该是要删除的资源的URI。 POST到的任何资源都是一种资源，它接受POSTed数据附加到自身，添加到集合或以其他方式处理。

HEAD 如果你关心的只是GET请求的标题，并且你不想在实际内容上浪费带宽，则使用它。这很好。

为什么我们需要的不仅仅是POST？它允许数据双向流动，那么为什么需要GET呢？答案与您的问题基本相同。通过标准化各种方法的基本期望，其他过程可以更好地知道该做什么。

例如，干预缓存代理可以更好地做正确的事情。

比如想想HEAD。如果代理服务器知道HEAD的含义，那么它可以处理来自先前GET请求的结果，以便为HEAD请求提供正确的答案。并且它可以知道不应该缓存POST，PUT和DELETE。

没有人发布我正在寻找的那种答案，所以我会尝试自己总结这些观点。

“RESTful Web服务”第8章“重载POST”部分读取：“如果你想完全没有PUT和DELETE，它完全是RESTful的，可以通过GET公开资源的安全操作，以及通过重载的POST公开所有其他操作。这样做违反了我的面向资源的体系结构，但它符合REST限制较少的规则。“

简而言之，替换PUT / DELETE而使用POST会使API难以阅读，而PUT / DELETE调用不再是幂等的。

总之：

幂等性

再补充一句话：

GET = safe + idempotent

PUT =幂等

DELETE = idempotent

POST =既不安全也不是幂等

'Idempotent'只是意味着你可以一遍又一遍地做到这一点，它总会做同样的事情。

您可以根据需要多次重新发出PUT（更新）或DELETE请求，并且每次都会产生相同的效果，但是所需的效果会修改资源，因此不会被视为“安全”。

POST请求应该为每个请求创建一个新资源，这意味着每次效果都不同。因此，POST不被认为是安全的或幂等的。

像GET和HEAD这样的方法只是读取操作，因此被认为是“安全的”以及幂等。

这实际上是一个非常重要的概念，因为它提供了一种标准/一致的方式来解释HTTP事务;这在安全上下文中特别有用。

并非所有主机都不支持PUT，DELETE。

我问过这个问题，在一个理想的世界里，我们有所有的动词，但是......：

RESTful网络服务和HTTP动词

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 ^日期

限制歧义，以便更好/更容易地重用我们简单的REST apis。

你只能使用GET和POST，但是你会失去PUT和DELETE带来的一些精确性和清晰度。 POST是一个通配符操作，可能意味着什么。 PUT和DELETE的行为定义非常明确。 如果您考虑使用资源管理API，那么GET，PUT和DELETE可能会覆盖80％-90％的所需功能。如果你限制自己使用GET和POST，那么使用指定不当的POST访问你的api的40％-60％。

使用GET和POST的Web应用程序允许用户创建，查看，修改和删除他们的数据，但是在最初为此目的创建的HTTP命令之上的层上执行此操作。 REST背后的一个想法是回归Web设计的初衷，即每个CRUD动词都有特定的HTTP操作。

此外，HEAD命令可用于改善（可能很大）文件下载的用户体验。您调用HEAD以查明响应的大小，然后调用GET以实际检索内容。

有关说明性示例，请参阅以下链接。它还提出了一种使用OPTIONS http方法的方法，这里还没有讨论过。

像WebDAV这样的http扩展需要额外的功能。

http://en.wikipedia.org/wiki/WebDAV

早期的网络服务器大战可能会引发它。

在1996年写的 HTTP 1.0中，只有GET，HEAD和POST 。但正如您在附录D 中所见，供应商开始添加他们的自己的东西。因此，为了保持HTTP兼容，他们被迫在1999年制作 HTTP 1.1

  

但是，HTTP / 1.0没有充分考虑   分层代理的影响，缓存，需要   持久连接或虚拟主机。此外，扩散   未完成实现的应用程序调用自己   ＆QUOT; HTTP / 1.0＆QUOT;因此需要更改协议版本   两个通信应用程序，以确定彼此的真正能力。

     

该规范定义了称为“HTTP / 1.1”的协议。该协议按顺序包含比HTTP / 1.0更严格的要求   确保其功能的可靠实施。

GET，PUT，DELETE和POST是一个二年级学生认为网页可以简化为一些忠诚原则的时代的延续。

如今，大多数网页都是复合实体，它们包含部分或全部这些基本操作。例如，页面可以包含用于查看或更新客户信息的表单，这些表单可能跨越多个表格。

我通常在php中使用$ _REQUEST []，而不是真正关心信息是如何到达的。我会选择使用基于效率的GET或PUT方法，而不是基础（多个）范例。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top