rest - 按照惯例应该返回哪些 REST PUT/POST/DELETE 调用？

Question

1. 根据“REST 思想”，PUT/POST/DELETE 请求的响应正文中应该包含什么？

2. 返回码呢？够HTTP_OK了吗？

3. 如果有的话，这些约定的原因是什么？

我找到了一篇描述 POST/PUT 差异的好帖子：POST vs PUT 但它仍然没有回答我的问题。

Answer 1

请原谅轻率，但如果您通过 HTTP 进行 REST，那么RFC7231准确描述了 GET、PUT、POST 和 DELETE 的预期行为。

更新（2014 年 7 月 3 日）：
HTTP 规范有意不定义从 POST 或 DELETE 返回的内容。规范只定义了需要定义的内容。其余的留给实施者选择。

Answer 2

总的来说，这些约定是“认为你只是在交付网页”。

对于 PUT，如果您在之后立即执行 GET，我将返回相同的视图；这将导致 200（当然，假设渲染成功）。对于 POST，我会重定向到创建的资源（假设您正在执行创建操作；如果没有，则只返回结果）；成功创建的代码是 201，它实际上是唯一一个不在 300 范围内的重定向 HTTP 代码。

我从来没有对 DELETE 应该返回的内容感到满意（在这种情况下，我的代码当前生成 HTTP 204 和空正文）。

Answer 3

创建资源通常映射到 POST，并且应该返回新资源的位置；例如，在 Rails 脚手架中，CREATE 将重定向到新创建资源的 SHOW。同样的方法可能对更新（PUT）有意义，但这不是惯例；更新只需要表明成功。删除可能也只需要表明成功；如果您想重定向，返回资源列表可能最有意义。

HTTP_OK可以表示成功，是的。

我上面所说的唯一一成不变的规则是 CREATE 应该返回新资源的位置。这对我来说似乎很容易。客户需要能够访问新项目是完全合理的。

Answer 4

根据 RFC7231 无关紧要，可能为空

我们如何在项目中实现基于 json api 标准的解决方案：

post/put：在 get 中输出对象属性（字段过滤器/关系应用相同）

删除：数据只包含空（因为它是丢失对象的表示）

标准删除状态：200

Answer 5

我喜欢 Alfonso Tienda 从 HTTP 状态代码响应更新和删除？

这里有一些提示：

删除

• 200（如果您想在响应中发送一些额外的数据）或204（推荐）。

• 202删除的操作尚未提交。

• 如果没有什么要删除的，就用204 或者 404（DELETE操作是幂等的，删除一个已经删除的项是操作成功，所以可以返回204，但确实幂等不一定表示同样的响应）

其他错误：

• 400 Bad Request（格式错误的语法或错误的查询很奇怪，但可能）。
• 401 未经授权的身份验证失败
• 403 Forbidden : 授权失败或无效的应用程序 ID。
• 405 不允许。当然。
• 409 资源冲突在复杂系统中是可能的。
• 和501 , 502以防出错。

放

如果您要更新集合的元素

• 200/204的原因与上面的 DELETE 相同。
• 202如果操作尚未提交。

引用的元素不存在：

• PUT 可以是201（如果您创建了元素，因为那是您的行为）

• 404如果您不想通过 PUT 创建元素。

• 400 错误请求（格式错误的语法或错误查询比 DELETE 更常见）。

• 401 未经授权

• 403 Forbidden : 身份验证失败或无效的应用程序 ID。

• 405 不允许。当然。

• 409 资源冲突在复杂系统中可能发生，例如在 DELETE 中。

• 422 Unprocessable entity它有助于区分“错误请求”（例如格式错误的 XML/JSON）和无效的字段值

• 和501 , 502以防出错。