根据约定，什么 REST PUT/POST/DELETE 调用应该返回？

小开

总的来说，这些惯例是“认为你只是在传递网页”。

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

对于 DELETE 应该返回什么内容，我从来都不感到高兴(我的代码当前生成一个 HTTP204，在本例中是一个空主体)。

小开

创建资源通常映射到 POST，这应该返回新资源的位置; 例如，在 Rails 脚手架中，CREATE 将重定向到新创建资源的 SHOW。同样的方法对于更新(PUT)可能也有意义，但这不是一种约定; 更新只需要表明成功。Delete 可能只需要表示成功; 如果您想要重定向，返回资源的 LIST 可能是最有意义的。

成功可以通过 HTTP _ OK 表示，是的。

我在上面所说的唯一的硬性规则是 CREATE 应该返回新资源的位置。对我来说，这似乎是显而易见的; 客户需要能够访问这个新项目，这完全说得通。

小开

最佳答案

请原谅我的轻率，但是如果您正在通过 HTTP 进行 REST，那么 RFC7231确切地描述了 GET、 PUT、 POST 和 DELETE 所期望的行为。

最新消息(七月三至十四日) :
HTTP 规范故意不定义从 POST 或 DELETE 返回的内容。规范只定义需要定义的内容。剩下的由实现者自己选择。

小开

由 RFC7231它不重要，可能是空的

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

Post/put: 输出 get 中的对象属性(字段过滤器/关系应用相同)

Data 只包含 null (因为它表示丢失的对象)

标准删除状态: 200

小开

我喜欢 Alfonso Tienda 的回应更新及删除 HTTP状态码？

以下是一些小贴士:

删除

200 (如果您希望在响应中发送一些附加数据)或 204(推荐)。

删除操作尚未执行。

如果没有什么可删除的，使用 204 或者 404(DELETE 操作是幂等的，删除一个已经删除的项目是 行动成功，所以你可以返回 204，但是幂等的确不一定意味着相同的响应)

其他错误:

400 错误请求(语法错误或错误查询是 很奇怪，但有可能)。

401 未经授权认证失败

403 禁止: 授权失败或应用程序 ID 无效。

405 不允许. 当然。

409 资源冲突在复杂系统中是可能的。

以及 501，502以防出错。

放

如果更新集合的元素

200/204 ，原因与上面的 DELETE 相同。

如果行动尚未进行，则为202。

引用的元素不存在:

PUT 可以是 201(如果您创建了元素，因为这是您的行为)

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

400 错误请求(语法错误或者查询错误比 DELETE 更常见)。

未经授权

403 禁止: 认证失败或应用程序 ID 无效。

405 不允许. 当然。

409 资源冲突在复杂系统中是可能的，比如在 DELETE 中。

422 无法处理的实体这有助于区分“坏请求”(例如，格式不正确的 XML/JSON)和无效的字段值

以及 501，502以防出错。