协慌网

它们似乎都在将数据发送到体内的服务器，那么什么使它们不同呢？

HTTP PUT：

PUT 将文件或资源放在特定的 URI 上，并确切地放在该 URI 上。如果该 URI 上已经有文件或资源，则 PUT 会替换该文件或资源。如果那里没有文件或资源，PUT 将创建一个。 PUT 是幂等的 ，但矛盾的是 PUT 响应不可缓存。

PUT 的 HTTP 1.1 RFC 位置

HTTP POST：

POST 将数据发送到特定的 URI，并期望该 URI 上的资源可以处理请求。此时，Web 服务器可以确定在指定资源的上下文中如何处理数据。 POST 方法不是幂等的 ，但是只要服务器设置适当的 Cache-Control 和 Expires 标头，POST 响应就可以缓存。

官方 HTTP RFC 指定 POST 为：

• 注释现有资源；
• 将消息发布到公告板，新闻组，邮件列表或类似的文章组；
• 向数据处理过程提供数据块，例如提交表单的结果；
• 通过附加操作扩展数据库。

POST 的 HTTP 1.1 RFC 位置

POST 和 PUT 之间的区别：

RFC 本身解释了核心区别：

POST 和 PUT 请求之间的根本区别体现在 Request-URI 的不同含义上。 POST 请求中的 URI 标识将处理封闭实体的资源。该资源可能是一个数据接受过程，某个其他协议的网关或一个接受注释的单独实体。相比之下，PUT 请求中的 URI 标识请求中包含的实体 - 用户代理知道 URI 的含义，并且服务器绝不能尝试将请求应用于其他资源。如果服务器希望将该请求应用于其他 URI，则它必须发送 301（永久移动）响应；然后，用户代理可以自行决定是否重定向请求。

此外，更简洁一点的是RFC 7231 第 4.3.4 节 PUT状态（添加了强调），

4.3.4。放

PUT 方法请求created目标资源的状态或replaced为请求消息有效负载中包含的表示形式所定义的状态。

使用正确的方法，除了无关的：

REST ROA与 SOAP 的一个好处是，当使用 HTTP REST ROA 时，它鼓励正确使用 HTTP 动词 / 方法。因此，例如，仅当您想在该确切位置创建资源时才使用 PUT。而且，您永远不会使用 GET 创建或修改资源。

仅语义。

HTTP PUT应该接受请求的主体，然后将其存储在 URI 标识的资源中。

HTTP POST更通用。应该在服务器上启动一个动作。该动作可以是将请求正文存储在 URI 标识的资源上，或者可以是其他 URI，或者可以是不同的动作。

PUT 就像文件上传一样。放入 URI 会完全影响该 URI。到 URI 的 POST 可能完全无效。

举例说明 REST 风格的资源：

带有大量书籍信息的 “POST / books” 可能会创建一本新书籍，并使用标识该书籍的新 URL 进行响应：“/ books / 5”。

“PUT / books / 5” 将必须创建 ID 为 5 的新书，或将 ID 为 5 的现有书替换。

在非资源风格中，POST 几乎可以用于任何具有副作用的东西。另一个不同之处在于，PUT 应该是幂等的 - 将相同数据的多个 PUT 放入相同的 URL 应该没问题，如果多个 POST 可能会创建多个对象，或者您的 POST 操作会执行任何操作。