RESTful'PUT'操作应该返回一些东西

Question

我想知道人们对RESTful PUT操作的意见是什么，它在响应主体中不返回任何内容（null）。

Answer 1

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

• HTTP状态代码200 OK，用于成功更新的PUT 现有资源。不需要响应机构。 （按Section 9.6，204 No Content更合适。）
• HTTP状态代码201 Created，用于新的成功PUT 资源，具有Location头字段中返回的新资源的最特定URI以及响应正文中回显的资源的任何其他相关URI和元数据。 （RFC 2616 Section 10.2.2）
• 未成功到期的PUT的HTTP状态代码409 Conflict 到3 ^rd -party修改，带有差异列表 尝试更新与响应中的当前资源之间的关系 身体。 （RFC 2616 Section 10.4.10）
• 不成功的HTTP状态代码400 Bad Request PUT，在响应主体中使用自然语言文本（例如英语） 这解释了为什么PUT失败了。 （RFC 2616 Section 10.4）

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

“创建”的Http响应代码为201，“Location”标题指向客户端可以找到新创建的资源的位置。

Answer 6

我在我的服务中使用了RESTful API，这是我的意见： 首先，我们必须达到一个共同的观点：#include <immintrin.h> int main() { float * ps = (float*)_mm_malloc(40, 32); double * pd = (double*)_mm_malloc(40, 32); __m256 s = Load(ps); //00007FF79FF81325 vmovdqa ymm1,ymmword ptr [rdi] __m256d d = Load(pd); //00007FF79FF8132F vmovdqa ymm0,ymmword ptr [rax] _mm256_storeu_ps(ps, s); _mm256_storeu_pd(pd, d); _mm_free(ps); _mm_free(pd); } 用于更新资源而不是创建或获取。

我使用以下内容定义了资源：PUT和Stateless resource：

• 无国籍资源 对于这些资源，只需返回带有空体的HttpCode就足够了。

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

但 ，对于服务或系统，保持Stateful resource，simple，clearly是最重要的事情。

Answer 7

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

1. 您应该在每条可以更新的记录中都具有 RowVersion （避免使用lost update problem）
2. 您应该在PUT之后始终返回记录的新副本（以获取新的 RowVersion ）。

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

Answer 8

Http 方法“PUT”可能根据传递的请求 URI 上的执行状态具有不同的 Http 状态。下表可能有助于理解——

Answer 9

似乎没问题......虽然我认为发布成功/失败/时间的初步迹象/＃字节收到/等等。会更好。

编辑：我正在考虑数据完整性和/或记录保存; MD5哈希值或接收时间的时间戳等元数据可能对大型数据文件有用。

Answer 10

就像空的Request主体符合GET请求的原始目的一样，空响应主体符合PUT请求的原始目的。

Answer 11

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

Answer 12

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