约定应返回哪些REST PUT / POST / DELETE调用？

1. 根据“ REST意识形态”，对于PUT / POST / DELETE请求，响应正文中应包含什么？

2. 那么返回码呢？是否HTTP_OK足够？

3. 制定此类约定的原因是什么？

我找到了一篇不错的文章来描述POST / PUT的区别：POST vs PUT， 但是它仍然无法回答我的问题。

原谅这种轻率，但是如果您正在通过HTTP执行REST，则RFC7231准确描述了GET，PUT，POST和DELETE预期的行为。

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

总体而言，约定是“认为您只是在交付网页”。

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

我从来都不满意DELETE应该返回什么（在这种情况下，我的代码当前会产生HTTP 204和空主体）。

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

可以通过HTTP_OK表示成功，是的。

我上面所说的唯一一成不变的规则是CREATE应该返回新资源的位置。对我而言，这似乎毫无疑问。完全有理由认为客户将需要能够访问新项目。

通过RFC7231没关系，可能为空

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

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

删除：数据仅包含null（因为它表示缺少的对象）

标准删除状态：200

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

这里有一些提示：

删除

• 200（如果要在响应中发送一些其他数据）或204（推荐）。

• 202删除操作尚未提交。

• 如果没有要删除的内容，请使用204 或 404（DELETE操作是幂等的，删除已删除的项目是成功的操作，因此您可以返回204，但是幂等不一定意味着相同的响应）

其他错误：

• 400 错误的请求（语法错误或错误的查询很奇怪，但可能）。
• 401 未经授权的身份验证失败
• 403 禁止：授权失败或无效的应用程序ID。
• 405 不允许。当然。
• 409 在复杂的系统中可能发生资源冲突。
• 而501，502在错误的情况下。

放

如果您要更新集合的元素

• 200/204，其原因与上述删除相同。
• 202，如果尚未提交操作。

所引用的元素不存在：

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

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

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

• 401 未经授权

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

• 405 不允许。当然。

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

• 422 无法处理的实体有助于区分“错误的请求”（例如，格式错误的XML / JSON）和无效的字段值

• 而501，502在错误的情况下。