理想情况下，它将返回一个成功/失败响应。

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

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

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

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

空的Request体符合GET请求的原始目的，空的响应体也符合PUT请求的原始目的。

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

与这里的大多数答案相反，我实际上认为PUT应该返回更新后的资源(当然除了HTTP代码之外)。

您希望将资源作为PUT操作的响应返回的原因是，当您向服务器发送资源表示时，服务器也可以对该资源应用一些处理，因此客户端希望知道请求成功完成后该资源的样子。(否则它将不得不发出另一个GET请求)。

HTTP规范(RFC 2616)有许多适用的建议。以下是我的解读:

HTTP status code 200 OK for a successful PUT of an update to an existing resource. No response body needed. (Per Section 9.6, 204 No Content is even more appropriate.) HTTP status code 201 Created for a successful PUT of a new resource, with the most specific URI for the new resource returned in the Location header field and any other relevant URIs and metadata of the resource echoed in the response body. (RFC 2616 Section 10.2.2) HTTP status code 409 Conflict for a PUT that is unsuccessful due to a 3rd-party modification, with a list of differences between the attempted update and the current resource in the response body. (RFC 2616 Section 10.4.10) HTTP status code 400 Bad Request for an unsuccessful PUT, with natural-language text (such as English) in the response body that explains why the PUT failed. (RFC 2616 Section 10.4)

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

我认为服务器可以返回内容以响应PUT。如果您正在使用允许侧载数据的响应信封格式(例如ember-data所使用的格式)，那么您还可以包括其他可能通过数据库触发器修改过的对象，等等(侧载数据显式地减少了请求的数量，这似乎是一个优化的好地方)。

如果我只是接受PUT，没有任何报告，我使用状态代码204，没有正文。如果我有什么要报告的，我会使用状态代码200，并包含一个主体。

我在我的服务中使用了RESTful API，以下是我的观点: 首先，我们必须了解一个通用视图:PUT用于更新资源，而不是创建或获取资源。

我用:无状态资源和有状态资源来定义资源:

无状态的资源 对于这些资源，只返回带有空主体的HttpCode就足够了。 有状态资源 例如:资源的版本。对于这类资源，当您想要更改它时，您必须提供版本，因此返回完整的资源或将版本返回给客户端，因此客户端在更新操作后不需要发送get请求。

但是，对于服务或系统来说，最重要的是保持简单、清晰、易于使用和维护。

如果REST API的后端是一个SQL关系数据库，那么

您应该在每个可以更新的记录中都有RowVersion(以避免丢失更新问题) 您应该总是在PUT之后返回记录的新副本(以获得新的RowVersion)。

如果您不关心丢失的更新，或者您希望强制客户端在PUT之后立即执行GET，那么不要从PUT返回任何东西。

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

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

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