HTTP 规范 (RFC 2616) 有许多适用的建议。这是我的解释：
HTTP 状态代码 200 OK 表示成功 PUT 更新现有资源。不需要响应体。 （根据第 9.6 节，204 没有内容更合适。）
HTTP 状态代码 201 为成功 PUT 新资源而创建，在 Location 标头字段中返回新资源的最具体 URI，并在响应正文中回显该资源的任何其他相关 URI 和元数据。 （RFC 2616 第 10.2.2 节）
HTTP 状态代码 409 由于第 3 方修改而失败的 PUT 冲突，并在响应正文中列出了尝试更新与当前资源之间的差异。 （RFC 2616 第 10.4.10 节）
HTTP 状态代码 400 对不成功 PUT 的错误请求，响应正文中包含解释 PUT 失败原因的自然语言文本（例如英语）。 （RFC 2616 第 10.4 节）
与这里的大多数答案相反，我实际上认为 PUT 应该返回更新的资源（当然除了 HTTP 代码）。
您之所以希望将资源作为 PUT 操作的响应返回是因为当您向服务器发送资源表示时，服务器也可以对该资源进行一些处理，因此客户端想知道该资源是如何处理的请求成功完成后的样子。 （否则它将不得不发出另一个 GET 请求）。
我认为服务器可以返回内容以响应 PUT。如果您正在使用允许侧载数据的响应信封格式（例如 ember-data 使用的格式），那么您还可以包含可能已通过数据库触发器等修改的其他对象。（侧载数据明确用于减少# 个请求，这似乎是一个优化的好地方。）
如果我只是接受 PUT 并且没有要报告的内容，我会使用没有正文的状态代码 204。如果我有什么要报告的，我会使用状态码 200，并包含一个正文。
如果 REST API 的后端是 SQL 关系数据库，那么
您应该在每条可以更新的记录中都有 RowVersion（以避免丢失更新问题），您应该始终在 PUT 之后返回记录的新副本（以获取新的 RowVersion）。
如果您不关心丢失的更新，或者如果您想强制您的客户在 PUT 之后立即执行 GET，那么不要从 PUT 返回任何内容。
HTTP/1.1 spec（第 9.6 节）讨论了适当的响应/错误代码。但是它没有解决响应内容。
你会期待什么？一个简单的 HTTP 响应代码（200 等）对我来说似乎很简单明了。
https://i.stack.imgur.com/JwL5C.png
“已创建”的 201 的 Http 响应代码以及“位置”标头指向客户端可以找到新创建的资源的位置。
我在我的服务中使用了 RESTful API，以下是我的看法： 首先我们必须有一个共同的观点： PUT 用于更新资源，而不是创建或获取。
我用 Stateless resource 和 Stateful resource 定义了资源：
无状态资源对于这些资源，只要返回一个空体的HttpCode，就足够了。
有状态的资源 例如：资源的版本。对于这种资源，要更改时必须提供版本，因此返回完整资源或将版本返回给客户端，因此客户端在更新操作后无需发送获取请求。
但是，对于一个服务或系统来说，保留它simple、clearly、easy to use and maintain是最重要的。
正如空的请求体符合 GET 请求的原始目的，而空的响应体符合 PUT 请求的原始目的。
似乎没问题...虽然我认为成功/失败/发布时间/收到的#字节/等的基本指示。会更好。
编辑：我在考虑数据完整性和/或记录保存；接收时间的元数据（例如 MD5 哈希或时间戳）可能对大型数据文件有帮助。
理想情况下，它将返回成功/失败响应。
HTTP 响应的标头和正文之间存在差异。 PUT 永远不应返回正文，而必须在标头中返回响应代码。成功就选200，不成功就选4xx。没有空返回码之类的东西。你为什么要这样做？
关注公众号
不定期副业成功案例分享
200用于 PUT、DELETE 或任何其他方法的内容。我错过了什么？比如Mozilla成为W3和IETF的老大？ ;) 或者他们可能只是从未听说过 Postel 的稳健性原则。No response body needed。事实上，与 PUT 相关的响应主体根本没有被提及。它只说明If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request.