根据“REST意识形态”，PUT / POST / DELETE请求的响应正文应该是什么？
返回代码怎么样？ HTTP_OK是否足够？
此类约定的原因是什么？
我发现了一篇描述POST / PUT差异的好文章：POST vs PUT 但它仍然没有回答我的问题。
答案 0 :(得分：128)
原谅轻率，但如果您通过HTTP进行REST，那么RFC7231将准确描述GET，PUT，POST和DELETE的预期行为。
更新（2014年7月3日）：
HTTP规范故意不定义从POST或DELETE返回的内容。规范只定义了需要定义的内容。剩下的由实施者来决定。
答案 1 :(得分：24)
总的来说，这些约定“就像你只是在提供网页一样”。
对于PUT，如果您之后立即执行GET，我将返回相同的视图;这将导致200（好吧，假设渲染成功当然）。对于POST，我会重定向到创建的资源（假设您正在进行创建操作;如果没有，只返回结果）;成功创建的代码是201，这实际上是不在300范围内的重定向的唯一HTTP代码。
我从未对DELETE应返回的内容感到满意（在这种情况下，我的代码当前生成了HTTP 204和空体）。
答案 2 :(得分：3)
创建资源通常映射到POST，并且应该返回新资源的位置;例如，在Rails脚手架中，CREATE将重定向到SHOW以获取新创建的资源。相同的方法可能对更新（PUT）有意义，但这不是一个惯例;更新只需表明成功。删除可能只需要指示成功;如果你想重定向，返回资源的LIST可能是最有意义的。
成功可以通过HTTP_OK表示，是的。
我上面所说的唯一的硬性规则是CREATE应该返回新资源的位置。这对我来说似乎不费吹灰之力;客户端需要能够访问新项目是完全合理的。
答案 3 :(得分：1)
通过RFC7231没关系，可能为空
我们如何在项目中实现基于json api标准的解决方案：
post / put：输出对象属性，如在get中一样（字段过滤器/关系应用相同）
删除：数据仅包含null（因为它表示丢失的对象）
标准删除的状态：200
答案 4 :(得分：0)
我喜欢来自的Alfonso Tienda回复 HTTP status code for update and delete?
以下是一些提示：
删除
200 （如果要在响应中发送一些其他数据）或 204 （推荐）。
202 删除操作尚未提交。
如果没有要删除的内容，请使用 204 或 404 （DELETE操作是幂等的，删除已删除的项目是< em>操作成功，因此您可以返回 204 ，但这是幂等的，不一定意味着相同的响应）
其他错误：
- 400 错误的请求（语法错误或查询错误奇怪，但可能）。
- 401 未授权身份验证失败
- 403 ：禁止：授权失败或无效的应用程序ID。
- 405 。不允许。当然。
在复杂的系统中可能出现- 409 资源冲突。
- 还有 501 ， 502 ，以防发生错误。
放置
如果您要更新集合的元素
- 200/204 ，其原因与上述“删除”相同。
- 202 （如果尚未提交操作）。
所引用的元素不存在：
PUT可以为 201 （如果您创建元素是因为这是您的行为）
404 如果您不想通过PUT创建元素。
400 错误的请求（语法错误或错误查询比DELETE更为常见）。
401 未授权
403 ：禁止：身份验证失败或无效的应用程序ID。
405 不允许。当然。
409 资源冲突在复杂的系统中可能会发生，例如在DELETE中。
422 不可处理的实体有助于区分“错误请求”（例如，格式错误的XML / JSON）和无效字段值
和 501 ， 502 ，以防出现错误。