PUT'操作返回一些东西....

我想知道人们对在响应体中不返回任何(null)的RESTful PUT操作有什么看法。

290147 次浏览
小开

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

小开

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

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

小开

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

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

小开

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

小开

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

小开

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

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

小开
最佳答案

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

  • HTTP状态码200 OK表示成功PUT更新到 现有的资源。不需要响应体。(根据9.6节， 204 No Content更合适)
  • HTTP状态码201 Created表示new . PUT成功 资源，其中包含Location报头字段中返回的新资源的最特定URI，以及响应体中返回的资源的任何其他相关URI和元数据。李(# EYZ0) < / >
  • HTTP状态码409 Conflict表示PUT不成功 到3# eyz0方修改，并列出差异 在尝试的更新和响应中的当前资源之间 的身体。李(# EYZ0) < / > HTTP状态码400 Bad Request表示不成功 PUT，在响应体中使用自然语言文本(如英语) 这解释了PUT失败的原因。李(# EYZ0) < / >
小开

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

小开

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

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

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

我用Stateless resource和Stateful resource定义资源:

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

< em >, < / em >，对于一个服务或系统，保持simple， clearly， easy to use and maintain是最重要的。

小开

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

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

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

小开

Http方法"根据传递的request-URI的执行状态，可能有不同的Http状态。下表可能有助于理解- # EYZ0 < / p >


提交答案