如果一个RESTful“PUT”操作返回一些东西

我想知道人们的意见是什么RESTful的“放”操作，返回什么（空）在响应正文？

HTTP规范（ RFC 2616 ）有许多适用的build议。这是我的解释：

HTTP状态码200 OK用于成功更新现有资源的PUT。没有响应身体需要。（根据9.6节， 204 No Content 节 204 No Content更加不恰当）
HTTP状态代码201 Created为一个新资源的成功PUT 201 Created ，在Location头部字段中返回的新资源具有最具体的URI，并且在响应主体中回传资源的任何其他相关URI和元数据。（ RFC 2616第10.2.2节）
HTTP状态代码409 Conflict由于第三方修改而导致PUT失败，其中列出了尝试更新和响应正文中的当前资源之间的差异。（ RFC 2616第10.4.10节）
HTTP状态代码400 Bad Request PUT失败，在响应正文中使用自然语言文本（例如英文）解释PUT失败的原因。（ RFC 2616第10.4节）

相对于这里的大部分答案，我实际上认为PUT应该返回更新的资源（当然除了HTTP代码之外）。

之所以要将资源作为PUT操作的响应返回，是因为当您向服务器发送资源表示时，服务器也可以对此资源应用一些处理，因此客户端想要知道此资源看起来像是在请求成功完成之后。（否则它将不得不发出另一个GET请求）。

Http响应代码201为“创build”以及“位置”头指向客户端可以find新创build的资源的位置。

HTTP / 1.1规范（9.6节）讨论了适当的响应/错误代码。但是它没有解决响应内容。

你会期待什么？一个简单的HTTP响应代码（200等）似乎对我来说简单明了。

我认为服务器可以返回内容来响应PUT。如果您使用的是允许侧载数据的响应信封格式（如ember-data所使用的格式），那么您还可以包含可能已经通过数据库触发器等进行了修改的其他对象（Sideloaded data is displayed to reduce请求数量，这似乎是一个优化的好地方。）

如果我只接受PUT而没有任何报告，我使用状态码204而没有任何内容。如果我有东西要报告，我使用状态码200，并包括一个正文。

我在我的服务中使用了RESTful API，这里是我的观点：首先，我们必须得到一个共同的看法： PUT用于更新不创build或获取的资源。

我用以下方式定义资源： Stateless resource和Stateful resource ：

无状态资源对于这些资源，只要返回空主体的HttpCode就足够了。
有状态的资源例如：资源的版本。对于这种资源，当你想要改变它的时候，你必须提供这个版本，所以返回完整的资源或者把版本返回给客户端，这样客户端不需要在更新动作之后发送一个get请求。

但是，对于服务或系统来说，保持simple ， clearly ， easy to use and maintain是最重要的。

HTTP响应的头部和主体之间有区别。 PUT不应该返回一个正文，但是必须在标题中返回一个响应代码。如果成功，就select200，如果不成功则select4xx。没有这样的东西作为空返回码。你为什么要这样做？

似乎没问题…虽然我会认为一个基本的成功/失败/时间张贴/＃字节收到/等指示。会更好。

编辑：我正在思考数据完整性和/或logging保存的问题。诸如MD5散列之类的元数据或所接收时间的时间戳可能对大型数据文件有帮助。

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

正如一个空的请求体与GET请求的原始目的保持一致，并且空的响应体符合PUT请求的原始目的。