我应该为UPDATE(PUT和DELETE设置什么状态代码(例如产品更新成功)？

对于Put请求：HTTP 200或HTTP 204应表示"已成功更新资源"。

对于删除请求：HTTP 200或HTTP 204应表示"已成功删除资源"。也可以返回HTTP 202，这意味着该指令已被服务器接受，并且"资源已标记为删除"。

来源：w3.org:http/1.1方法定义

HTTP 200 OK: Standard response for successful HTTP
requests. The actual response will
depend on the request method used.

HTTP 204 No Content: The server successfully processed the request, but is not returning any content

来源：HTTP状态代码列表：2xx成功

简短回答：对于Put和Delete，您应该发送200(确定)或204(无内容)。

答案很长：这里有一个完整的决策图(点击放大)。

来源：https://github.com/for-get/http-decision-diagram

以下是一些提示：

删除

• 200 (if you want send some additional data in the Response) or 204 (recommended).

• 202 Operation deleted has not been committed yet.

• 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)

Other errors:

• 400 Bad Request (Malformed syntax or a bad query is strange but possible).
• 401 Unauthorized Authentication failure
• 403 Forbidden: Authorization failure or invalid Application ID.
• 405 Not Allowed. Sure.
• 409 Resource Conflict can be possible in complex systems.
• And 501, 502 in case of errors.

放

If you're updating an element of a collection

• 200/204 with the same reasons as DELETE above.
• 202 if the operation has not been commited yet.

The referenced element doesn't exists:

• PUT can be 201 (if you created the element because that is your behaviour)

• 404 If you don't want to create elements via PUT.

• 400 Bad Request (Malformed syntax or a bad query more common than in case of DELETE).

• 401 Unauthorized
• 403 Forbidden: Authentication failure or invalid Application ID.
• 405 Not Allowed. Sure.
• 409 Resource Conflict can be possible in complex systems, as in DELETE.
• 422 Unprocessable entity It helps to distinguish between a"Bad request" (e.g. malformed XML/JSON) and invalid field values
• And 501, 502 in case of errors.

RFC2616描述了要使用的状态代码。

不，不总是200。

除了200和204，205(重置内容)可能是有效的响应。

The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent ... [e.g.] clearing of the form in which the input is given.

由于问题涉及到删除是否"应该"返回200对204，因此值得考虑的是，有些人建议返回带有链接的实体，因此首选的是200。

"Instead of returning 204 (No Content), the API should be helpful and
suggest places to go. In this example I think one obvious link to
provide is to" 'somewhere.com/container/' (minus 'resource')"- the container from which
the client just deleted a resource. Perhaps the client wishes to
delete more resources, so that would be a helpful link."

http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoint-204-responses/

If a client encounters a 204 response, it can either give up, go to
the entry point of the API, or go back to the previous resource it
visited. Neither option is particularly good.

就我个人而言，我不会说204是错误的(作者也不会，他说"烦人")，因为在客户端进行良好的缓存有很多好处。最好的办法是保持一致。

2014年6月，RFC7231废除了RFC2616。如果您正在通过HTTP执行REST，那么rfc7231将准确描述get、put、post和delete的预期行为。

修改资源时，响应代码应为200("OK")。如果资源状态的更改方式将URI更改为资源(例如，重命名用户帐户)，则响应代码为301("永久移动")，并且位置头应提供新的URI。

删除对象时，响应代码应为200("OK")。

有关详细信息，请访问以下链接--休息状态代码