我同意上面投票最多的答案，但我想更详细地说明这一点。

REST不是一个标准，因此每个人都可以创建和记录自己的API，只要它符合目的，并且得到了良好的文档记录，得到了开发人员和消费者的同意和理解。 真正重要的是url标识了公开的资源。 我已经使用Http Rest api很多年了，我想分享我通常使用的标准方法，不是因为它是完美的，或者“行为规则”，只是因为我发现它很容易使用并向他人解释。

请注意，我没有提到超媒体，因为这远远超出了回答的目的，我宁愿把它放在范围之外，但如果有兴趣，可以在OData规范中找到一份不错的阅读材料。

Create
---------------------------------------------------------------------
Success - 201 Created - Return created object
Failure - 400 Invalid request - Return details about the failure
Async fire and forget operation - 202 Accepted - Optionally return url for polling status

Update
---------------------------------------------------------------------
Success - 200 Ok - Return the updated object
Success - 204 NoContent
Failure - 404 NotFound - The targeted entity identifier does not exist
Failure - 400 Invalid request - Return details about the failure
Async fire and forget operation - 202 Accepted - Optionally return url for polling status

Patch
---------------------------------------------------------------------
Success - 200 Ok - Return the patched object
Success - 204 NoContent
Failure - 404 NotFound - The targeted entity identifier does not exist
Failure - 400 Invalid request - Return details about the failure
Async fire and forget operation - 202 Accepted - Optionally return url for polling status

Delete
---------------------------------------------------------------------
Success - 200 Ok - No content
Success - 200 Ok - When element attempting to be deleted does not exist
Async fire and forget operation - 202 Accepted - Optionally return url for polling status

Get
---------------------------------------------------------------------
Success - 200 Ok - With the list of resulting entities matching the search criteria
Success - 200 Ok - With an empty array

Get specific
---------------------------------------------------------------------
Success - 200 Ok - The entity matching the identifier specified is returned as content
Failure - 404 NotFound - No content

Action
---------------------------------------------------------------------
Success - 200 Ok - Return content where appropriate
Success - 204 NoContent
Failure - 400 - Return details about the failure
Async fire and forget operation - 202 Accepted - Optionally return url for polling status

Generic results
---------------------------------------------------------------------
Authorization error 401 Unauthorized
Authentication error 403 Forbidden
For methods not supported 405
Generic server error 500

HTTP响应的头和正文之间是有区别的。PUT永远不应该返回正文，但必须在报头中返回响应代码。如果成功就选择200，如果不成功就选择4xx。没有空返回码这样的东西。你为什么想做这个?

Http方法“PUT”可能具有不同的Http状态，根据传递的请求- uri的执行状态。下表可能有助于理解-

“Created”的Http响应代码201以及指向客户端可以找到新创建资源的“Location”标头。

HTTP/1.1规范(第9.6节)讨论了适当的响应/错误代码。但是，它不处理响应内容。

你想要什么?一个简单的HTTP响应代码(200等)对我来说似乎是直接而明确的。

看起来好…虽然我认为一个基本的指示成功/失败/时间张贴/#字节接收/等等。会更好。

编辑:我一直在考虑数据完整性和/或记录保存;元数据，如MD5散列或接收时间的时间戳，可能对大型数据文件有帮助。