519

我想知道人们对PUT在响应正文中不返回任何内容（null）的 RESTful 操作有何看法。

4

12 回答 12

705

HTTP 规范 ( RFC 2616 ) 有许多适用的建议。这是我的解释：

  • 200 OK成功 PUT 更新现有资源的HTTP 状态代码。不需要响应体。（根据第 9.6 节，204 No Content更合适。）
  • 新资源成功 PUT 的HTTP 状态代码201 Created，在 Location 标头字段中返回新资源的最具体 URI，在响应正文中回显该资源的任何其他相关 URI 和元数据。（RFC 2616 第 10.2.2 节）
  • 409 Conflict由于第 3 方修改而失败的 PUT 的HTTP状态代码，并在响应正文中列出了尝试更新与当前资源之间的差异。（RFC 2616 第 10.4.10 节）
  • 不成功 PUT 的HTTP 状态代码400 Bad Request，响应正文中的自然语言文本（例如英语）解释了 PUT 失败的原因。（RFC 2616 第 10.4 节）
于 2009-05-05T21:44:54.577 回答
207

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

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

于 2009-04-28T14:13:25.093 回答
7

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

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

于 2014-12-31T10:00:35.620 回答
3

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

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

于 2009-04-28T13:13:01.527 回答
3

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

  1. 您应该在可以更新的每条记录中都有RowVersion （以避免丢失更新问题）
  2. 您应该始终在 PUT 之后返回记录的新副本（以获取新的RowVersion）。

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

于 2019-02-05T20:30:13.477 回答
1

Http 方法“PUT”可能根据传递的请求 URI 上的执行状态具有不同的 Http 状态。下表可能有助于理解 - 在此处输入图像描述

于 2021-07-24T05:55:44.020 回答
0

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

于 2012-07-31T18:37:08.147 回答
0

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

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

  • 无状态资源对于这些资源，只要返回一个空体的HttpCode，就足够了。

  • 有状态的资源 例如：资源的版本。对于这种资源，要更改时必须提供版本，因此返回完整资源或将版本返回给客户端，因此客户端在更新操作后无需发送获取请求。

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

于 2017-03-29T12:32:27.777 回答
-3

似乎没问题...虽然我认为成功/失败/发布时间/收到的#字节/等的基本指示。会更好。

编辑：我在考虑数据完整性和/或记录保存；接收时间的元数据（例如 MD5 哈希或时间戳）可能对大型数据文件有帮助。

于 2009-04-28T13:10:17.943 回答
-3

正如空的请求体符合 GET 请求的原始目的，而空的响应体符合 PUT 请求的原始目的。

于 2009-04-28T13:13:33.100 回答
-5

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

于 2009-04-28T13:10:05.933 回答
-5

HTTP 响应的标头和正文之间存在差异。PUT 永远不应返回正文，而必须在标头中返回响应代码。成功就选200，不成功就选4xx。没有空返回码之类的东西。你为什么要这样做？

于 2009-04-28T13:15:09.523 回答