Put 与 Post - REST

Question

在查看 Spring 3.0 示例的一部分“petclinic”中的代码时，我注意到以下几行在

<c:choose>
  <c:when test="${owner.new}"><c:set var="method" value="post"/></c:when>
  <c:otherwise><c:set var="method" value="put"/></c:otherwise>
</c:choose>

SO 看来 PUT 应该用于“创建/更新”，POST 应该用于“更新”。

哪个是对的？

使用 post 进行“创建”并使用 put 进行“更新”有何影响？

注意：根据 HTTP/1.1 规范。在引用的 SO 讨论中引用，上面给出的代码似乎具有正确的行为。

Answer 1

根据 HTTP 规范，POST 和 PUT 都有明确定义的行为。

POST请求的结果应该是一个从属于请求URL的新资源；响应应包含带有新创建资源的 URL 的 Location 标头。

PUT 的结果应该是请求 URL 处资源的更新。如果请求 URL 处不存在现有资源，则可以创建一个新资源。

造成混乱的原因是 POST 也与表单一起使用作为传递表单数据的机制。最常见的表单实现是回发到表单页面所在的同一 URL，从而产生 POST 操作用于更新的错误想法。然而，在这个特定的用法中，表单页面不是资源。

考虑到所有这些，这是正确的（当然是我认为的:-)）用法：

在以下情况下应该使用 POST 来创建新资源：
- 新资源从属于现有资源
- 在创建时资源身份/URL 未知。

应使用 PUT 来更新具有已知 URL 的现有资源。它也可用于在众所周知的 URL 处创建资源；但是，以不同的方式考虑这种情况确实有帮助 - 如果在发出 PUT 请求之前已知资源 URL，则可以将其视为与该位置处已存在但为空的资源相同。

Answer 2

这非常简单：

• POST 允许任何事情发生，并且它不限于创建“从属”资源，而是允许客户端“提供数据块...... . 到数据处理过程” (RFC 2616 秒 9.5)。 POST 的意思是“这是您刚才请求的数据”
• PUT 与 GET 相反。通常的流程是，您 GET 一个资源，以某种方式修改它，然后将它放回您从中获取它的同一 URI。 PUT 表示“请将此文件存储在此 URI 中”。

PUT（用于存储文件）的统一性允许中介（例如缓存）使任何缓存的响应无效他们可能在该确切的 URI 上（因为他们知道它是即将改变）。 PUT 的统一性还允许客户端（理解这一点）通过首先检索资源 (GET) 来修改资源，然后发回修改后的副本（PUT）。由于 PUT 的幂等性，它还允许客户端在网络故障时重试。

旁注：使用 PUT 创建资源是值得怀疑的。虽然在规范中这是可能的，但我不认为这是一个好主意，就像使用 POST 执行搜索不是一个好主意一样，就像通过 HTTP 建立 SOAP 隧道也不是一个好主意一样。 AtomPub 明确指出 PUT 不用于创建原子条目。

POST 的普遍存在源于这样一个事实：HTML 定义了

元素，这些元素导致 POST 一个 application/x-www-form-urlencoded实体，接收者可以用它做任何它想做的事情，包括

• 创建从属资源（响应通常伴随着 201 响应和 Location 标头）
• 创建完全不同的资源（通常是 201 响应和 Location 标头）
• 创建许多从属和/或不相关的资源（可能有一个简单的响应指示所创建资源的 URI），
• 除了返回一个响应（例如 200 或 302）（可能应该使用 GET 的情况）
• 修改接收 POST 本身的资源（返回或重定向回更新的资源） 。
• 删除一项或多项资源。
• 上述任意组合。

唯一知道 POST 请求中会发生什么的人是发起请求的用户（通过单击巨大的“是的，我确认删除我的 Facebook 个人资料”按钮）和处理该请求的服务器。对于世界其他地方来说，该请求是不透明的，除了“此 URI 正在传递一些数据”之外没有任何意义。

因此，您问题的答案是 POST 和 PUT 都可以用于创建和更新。

1. POST 通常用于创建资源（例如 AtomPub 9.2）
2. PUT 语义非常适合修改资源（例如 AtomPub 9.3)
3. POST 可用于修改资源（如 www 表单编辑您的个人资料）
4. PUT 在技术上可用于创建资源（尽管我建议不要这样做）