blocks|key|3008801|text|请原谅我的轻率，但是如果你在HTTP上做REST，那么RFC7231准确地描述了GET，PUT，POST和DELETE的行为。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3008802|更新(2014年7月3日)：|style|BOLD|3008803|HTTP规范有意没有定义从POST或DELETE返回的内容。规范只定义了需要定义的内容。剩下的留给实现者来选择。|3008804|entityMap|0|LINK|mutability|MUTABLE|url|https://www.rfc-editor.org/rfc/rfc7231#section-4.3^0|R|7|0|0|0|E|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@$A|W|B|X|F|G]]|9|@]|C|$]]|$1|H|3|I|5|6|7|Y|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]]]

Forgive the flippancy, but if you are doing REST over HTTP then <a href="https://www.rfc-editor.org/rfc/rfc7231#section-4.3" rel="nofollow noreferrer">RFC7231</a> describes exactly what behaviour is expected from GET, PUT, POST and DELETE.
Update (Jul 3 '14): 
The HTTP spec intentionally does not define what is returned from POST or DELETE. The spec only defines what needs to be defined. The rest is left up to the implementer to choose.

blocks|key|290842|text|总体而言，约定是“就像你只是在传递网页一样思考”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|290843|对于PUT，我返回的视图与在get之后立即返回的视图相同；这将导致200+(当然，假设渲染成功)。对于POST，我会重定向到创建的资源(假设您正在执行创建操作；如果不是，只返回结果)；成功创建的代码是201，这实际上是唯一不在300范围内的重定向HTTP代码。|290844|对于DELETE应该返回什么，我从来都不满意(在这种情况下，我的代码当前生成一个HTTP204和一个空的正文)。|290845|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Overall, the conventions are “think like you're just delivering web pages”.

For a PUT, I'd return the same view that you'd get if you did a GET immediately after; that would result in a 200 (well, assuming the rendering succeeds of course). For a POST, I'd do a redirect to the resource created (assuming you're doing a creation operation; if not, just return the results); the code for a successful create is a 201, which is really the only HTTP code for a redirect that isn't in the 300 range.

I've never been happy about what a DELETE should return (my code currently produces an HTTP 204 and an empty body in this case).

blocks|key|3222810|text|创建资源通常映射到POST，这应该返回新资源的位置；例如，在Rails+scaffold中，CREATE将重定向到新创建的资源的SHOW。同样的方法对于更新(PUT)可能是有意义的，但这不是一种约定；更新只需要表明成功。delete可能也只需要指示成功；如果您想要重定向，返回资源列表可能是最有意义的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3222811|成功可以通过HTTP_OK来表示，是的。|3222812|我在上面说过的唯一一条硬性规则是，创建应该返回新资源的位置。对我来说，这似乎是不费吹灰之力的；客户端将需要能够访问新项目，这是非常有意义的。|3222813|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Creating a resource is generally mapped to POST, and that should return the location of the new resource; for example, in a Rails scaffold a CREATE will redirect to the SHOW for the newly created resource. The same approach might make sense for updating (PUT), but that's less of a convention; an update need only indicate success. A delete probably only needs to indicate success as well; if you wanted to redirect, returning the LIST of resources probably makes the most sense.

Success can be indicated by HTTP_OK, yes.

The only hard-and-fast rule in what I've said above is that a CREATE should return the location of the new resource. That seems like a no-brainer to me; it makes perfect sense that the client will need to be able to access the new item.

blocks|key|290870|text|对于RFC7231，它无关紧要，可能是空的|type|unstyled|depth|inlineStyleRanges|entityRanges|data|290871|如何在项目中实现基于json+api标准的解决方案：|290872|post/put:输出get中的对象属性(字段过滤器/关系应用相同)|290873|delete:数据只包含null+(因为它是缺少对象的表示)|290874|标准删除状态:+200|290875|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

By the RFC7231 it does not matter and may be empty

How we implement json api standard based solution in the project:

post/put: outputs object attributes as in get (field filter/relations applies the same)

delete: data only contains null (for its a representation of missing object)

status for standard delete: 200

blocks|key|3008843|text|我喜欢来自HTTP+status+code+for+update+and+delete?的阿方索·蒂恩达回复|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3008844|这里有一些小贴士：|3008845|删除|style|BOLD|3008846|3008847|blockquote|3008848|3008849|3008850|200+(如果要在响应中发送一些附加数据)或(recommended).|unordered-list-item|3008851|+204|3008852|尚未提交已删除的|3008853|202操作。|3008854|3008855|3008856|如果没有要删除的内容，请使用204或404+(删除操作是幂等的，删除已经删除的项是操作成功，因此可以返回204，但幂等不一定意味着相同的响应)|3008857|3008858|其他错误：|3008859|应用程序错误请求(语法错误或查询错误很奇怪，但possible).|3008860|401未授权身份验证failure|3008861|
|3008862|403禁止:不允许授权失败或无效的应用程序ID.|3008863|3008864|405。在复杂的系统中可能会出现资源冲突。|3008865|3008866|和501，502在出现错误的情况下。|3008867|3008868|PUT|3008869|如果要更新集合的元素，则为|3008870|3008871|3008872|3008873|如果操作尚未提交，请使用与|3008874|200/204+above.|3008875|202相同的原因删除。|3008876|3008877|引用的元素不存在：|3008878|3008879|PUT可以是201+(如果您创建了元素，因为这是您的行为)|3008880|3008881|如果不想通过PUT.创建元素，则为|3008882|404|3008883|3008884|3008885|400错误请求(语法错误或错误查询比DELETE更常见)。|3008886|3008887|3008888|401+Unauthorized|3008889|3008890|3008891|403禁止:身份验证失败或应用程序ID无效。|3008892|3008893|不允许使用|3008894|405。当然。|3008895|3008896|在复杂的系统中可能会发生资源冲突，例如在|3008897|409中。|3008898|3008899|3008900|422无法处理的实体它有助于区分“错误的请求”(例如，格式错误的XML/JSON)和无效的字段值|3008901|3008902|3008903|和501，502以防出现错误。|3008904|3008905|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/2342579/http-status-code-for-update-and-delete^0|5|13|0|0|0|0|2|0|0|0|0|0|0|3|0|1|3|0|0|0|3|0|0|0|E|3|I|3|1G|3|0|0|0|0|0|3|0|0|0|3|0|0|0|3|0|0|1|3|5|3|0|0|0|3|0|0|0|0|0|0|0|7|0|0|3|0|0|0|0|6|3|0|0|0|0|3|0|0|0|0|3|0|0|0|0|3|0|0|0|0|3|0|0|0|0|3|0|0|0|0|3|0|0|0|0|3|0|0|0|1|3|5|3|0|0^^$0|@$1|2|3|4|5|6|7|3A|8|@]|9|@$A|3B|B|3C|1|3D]]|C|$]]|$1|D|3|E|5|6|7|3E|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|3F|8|@$A|3G|B|3H|H|I]]|9|@]|C|$]]|$1|J|3|-4|5|6|7|3I|8|@]|9|@]|C|$]]|$1|K|3|-4|5|L|7|3J|8|@]|9|@]|C|$]]|$1|M|3|-4|5|6|7|3K|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|3L|8|@]|9|@]|C|$]]|$1|O|3|P|5|Q|7|3M|8|@$A|3N|B|3O|H|I]]|9|@]|C|$]]|$1|R|3|S|5|6|7|3P|8|@$A|3Q|B|3R|H|I]]|9|@]|C|$]]|$1|T|3|U|5|6|7|3S|8|@]|9|@]|C|$]]|$1|V|3|W|5|Q|7|3T|8|@$A|3U|B|3V|H|I]]|9|@]|C|$]]|$1|X|3|-4|5|6|7|3W|8|@]|9|@]|C|$]]|$1|Y|3|-4|5|6|7|3X|8|@]|9|@]|C|$]]|$1|Z|3|10|5|Q|7|3Y|8|@$A|3Z|B|40|H|I]|$A|41|B|42|H|I]|$A|43|B|44|H|I]]|9|@]|C|$]]|$1|11|3|-4|5|6|7|45|8|@]|9|@]|C|$]]|$1|12|3|13|5|6|7|46|8|@]|9|@]|C|$]]|$1|14|3|15|5|6|7|47|8|@]|9|@]|C|$]]|$1|16|3|17|5|Q|7|48|8|@$A|49|B|4A|H|I]]|9|@]|C|$]]|$1|18|3|19|5|6|7|4B|8|@]|9|@]|C|$]]|$1|1A|3|1B|5|Q|7|4C|8|@$A|4D|B|4E|H|I]]|9|@]|C|$]]|$1|1C|3|19|5|6|7|4F|8|@]|9|@]|C|$]]|$1|1D|3|1E|5|Q|7|4G|8|@$A|4H|B|4I|H|I]]|9|@]|C|$]]|$1|1F|3|19|5|6|7|4J|8|@]|9|@]|C|$]]|$1|1G|3|1H|5|Q|7|4K|8|@$A|4L|B|4M|H|I]|$A|4N|B|4O|H|I]]|9|@]|C|$]]|$1|1I|3|-4|5|6|7|4P|8|@]|9|@]|C|$]]|$1|1J|3|1K|5|6|7|4Q|8|@$A|4R|B|4S|H|I]]|9|@]|C|$]]|$1|1L|3|1M|5|6|7|4T|8|@]|9|@]|C|$]]|$1|1N|3|-4|5|L|7|4U|8|@]|9|@]|C|$]]|$1|1O|3|-4|5|6|7|4V|8|@]|9|@]|C|$]]|$1|1P|3|-4|5|6|7|4W|8|@]|9|@]|C|$]]|$1|1Q|3|1R|5|6|7|4X|8|@]|9|@]|C|$]]|$1|1S|3|1T|5|Q|7|4Y|8|@$A|4Z|B|50|H|I]]|9|@]|C|$]]|$1|1U|3|1V|5|Q|7|51|8|@$A|52|B|53|H|I]]|9|@]|C|$]]|$1|1W|3|-4|5|6|7|54|8|@]|9|@]|C|$]]|$1|1X|3|1Y|5|6|7|55|8|@]|9|@]|C|$]]|$1|1Z|3|-4|5|6|7|56|8|@]|9|@]|C|$]]|$1|20|3|21|5|Q|7|57|8|@$A|58|B|59|H|I]]|9|@]|C|$]]|$1|22|3|-4|5|6|7|5A|8|@]|9|@]|C|$]]|$1|23|3|24|5|6|7|5B|8|@]|9|@]|C|$]]|$1|25|3|26|5|Q|7|5C|8|@$A|5D|B|5E|H|I]]|9|@]|C|$]]|$1|27|3|-4|5|6|7|5F|8|@]|9|@]|C|$]]|$1|28|3|-4|5|6|7|5G|8|@]|9|@]|C|$]]|$1|29|3|2A|5|Q|7|5H|8|@$A|5I|B|5J|H|I]]|9|@]|C|$]]|$1|2B|3|-4|5|6|7|5K|8|@]|9|@]|C|$]]|$1|2C|3|-4|5|6|7|5L|8|@]|9|@]|C|$]]|$1|2D|3|2E|5|Q|7|5M|8|@$A|5N|B|5O|H|I]]|9|@]|C|$]]|$1|2F|3|-4|5|6|7|5P|8|@]|9|@]|C|$]]|$1|2G|3|-4|5|6|7|5Q|8|@]|9|@]|C|$]]|$1|2H|3|2I|5|Q|7|5R|8|@$A|5S|B|5T|H|I]]|9|@]|C|$]]|$1|2J|3|-4|5|6|7|5U|8|@]|9|@]|C|$]]|$1|2K|3|2L|5|6|7|5V|8|@]|9|@]|C|$]]|$1|2M|3|2N|5|Q|7|5W|8|@$A|5X|B|5Y|H|I]]|9|@]|C|$]]|$1|2O|3|-4|5|6|7|5Z|8|@]|9|@]|C|$]]|$1|2P|3|2Q|5|6|7|60|8|@]|9|@]|C|$]]|$1|2R|3|2S|5|Q|7|61|8|@$A|62|B|63|H|I]]|9|@]|C|$]]|$1|2T|3|-4|5|6|7|64|8|@]|9|@]|C|$]]|$1|2U|3|-4|5|6|7|65|8|@]|9|@]|C|$]]|$1|2V|3|2W|5|Q|7|66|8|@$A|67|B|68|H|I]]|9|@]|C|$]]|$1|2X|3|-4|5|6|7|69|8|@]|9|@]|C|$]]|$1|2Y|3|-4|5|6|7|6A|8|@]|9|@]|C|$]]|$1|2Z|3|30|5|Q|7|6B|8|@$A|6C|B|6D|H|I]|$A|6E|B|6F|H|I]]|9|@]|C|$]]|$1|31|3|-4|5|6|7|6G|8|@]|9|@]|C|$]]|$1|32|3|-4|5|6|7|6H|8|@]|9|@]|C|$]]]|33|$34|$5|35|36|37|C|$38|39]]]]

I like Alfonso Tienda responce from
<a href="https://stackoverflow.com/questions/2342579/http-status-code-for-update-and-delete">HTTP status code for update and delete?</a>
Here are some Tips:
DELETE
<blockquote>
<ul>
<li>200 (if you want send some additional data in the Response) or 204 (recommended).
</li>
<li>202 Operation deleted has not been committed yet.
</li>
<li>If there's nothing to delete, use 204 or 404 (DELETE operation is idempotent, delete an already deleted item is operation successful, so you can return 204, but it's true that idempotent doesn't necessarily imply the same response)
</li>
</ul>
Other errors:
<ul>
<li>400 Bad Request (Malformed syntax or a bad query is strange but possible).</li>
<li>401 Unauthorized Authentication failure</li>
<li>403 Forbidden: Authorization failure or invalid Application ID.</li>
<li>405 Not Allowed. Sure.</li>
<li>409 Resource Conflict can be possible in complex systems.</li>
<li>And 501, 502 in case of errors.</li>
</ul>
</blockquote>
PUT
<blockquote>
If you're updating an element of a collection
<ul>
<li>200/204 with the same reasons as DELETE above.</li>
<li>202 if the operation has not been commited yet.</li>
</ul>
The referenced element doesn't exists:
<ul>
<li>PUT can be 201 (if you created the element because that is your behaviour)
</li>
<li>404 If you don't want to create elements via PUT.
</li>
<li>400 Bad Request (Malformed syntax or a bad query more common than in case of DELETE).
</li>
<li>401 Unauthorized
</li>
<li>403 Forbidden: Authentication failure or invalid Application ID.
</li>
<li>405 Not Allowed. Sure.
</li>
<li>409 Resource Conflict can be possible in complex systems, as in DELETE.
</li>
<li>422 Unprocessable entity It helps to distinguish between a &quot;Bad request&quot; (e.g. malformed XML/JSON) and invalid field values
</li>
<li>And 501, 502 in case of errors.
</li>
</ul>
</blockquote>

<ol>
<li>According to the "REST ideology" what should be in the response body for a PUT/POST/DELETE requests?</li>
<li>What about return codes? Is <code>HTTP_OK</code> enough?</li>
<li>What is the reason for such conventions, if any?</li>
</ol>

I've found a good post describing POST/PUT differences: <a href="http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/" rel="noreferrer">POST vs PUT</a>
But it still doesn't answer my question.

What REST PUT/POST/DELETE calls should return by a convention?

身份验证

JSON

根据"REST思想“，PUT/POST/DELETE请求的响应体应该是什么？返回代码呢？HTTP_OK足够了吗？如果有这样的约定，原因是什么？我找到了一个描述POST/PUT差异的好帖子：，但它仍然没有回答我的问题。

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

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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