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

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

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

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

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

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

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

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

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

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