代码之家 › 专栏 › 技术社区 › HairOfTheDog

修补集合时的响应正文

http-patch http-put put rest

HairOfTheDog · 技术社区 · 5 年前

在我的REST API中,我有一个非常大的集合;它包含数以百万计的物品。此集合的路径是 /mycollection

因为这个藏品太大了,不适合收藏 GET 整个集合,因此API支持分页。分页将是获取集合的主要方式

GET /mycollection?page=1&page-size=100 HTTP/1.1

假设原始集合包含1000000个项目,我想更新5000个,删除3000个,添加2000个项目。我可以编写API来支持通过 PUT 方法还是 PATCH 方法虽然两种方法都需要非常不同的请求机构,但我相信两种方法都需要完全相同的响应机构,即响应机构必须包含整个更新资源的当前表示,即集合中的所有99.9万项。

正如我之前提到的 收到 整个系列都不现实;太大了。出于同样的原因我不想 放 还是 色斑 我想把所有的藏品都退回。将查询参数添加到 放 或 色斑 请求也不起作用,因为两者都不起作用 放 也没有 色斑 都是安全的方法。

那么,在这种大规模收集的情况下,正确的反应是什么呢?

我可以用

HTTP/1.1 202 Accepted
Location: /mycollection?page=1&page-size=100

这个 202 Accepted 响应代码感觉不正确,因为更新应该是同步完成的。这个 Location 头球也不太对劲。我也许可以和一个朋友一起去 Links 头球,但还是感觉不对。

我再次问,在这种大规模收集的情况下,正确的反应是什么?

0 回复 | 直到 5 年前

Evert 5 年前

这个问题基于一种误解:

虽然这两种方法都需要非常不同的请求机构,但我相信这两种方法都需要完全相同的响应机构,即响应机构必须包含整个更新资源的当前表示

两人都可以回来 204 No Content 或 200 OK 没有反应的身体。没有要求他们在回复中包含完整的陈述。

您可以选择支持这一点(可能与 Prefer: return=representation 头,或者 Content-Location header),但如果没有这个header,我想说返回当前表示甚至不是一种惯例。通用客户端 不应该 假设响应主体是新的表示形式,除非使用了这些头。

所以,只需返回一个 2xx 你可以走了。

Community Mohan Dere 5 年前

那么,在这种大规模收集的情况下,正确的反应是什么呢?

简短版本:你可能应该把一个成功的看跌期权当作一篇成功的帖子来对待。

有效载荷的预期含义可概括为: 行为状态或结果的表示

因此,答案可以简单到

200 OK
Content-Type: text/plain

It worked!

更详细的回答:

虽然这两种方法都需要非常不同的请求机构,但我相信这两种方法都需要完全相同的响应机构,即响应机构必须包含整个更新资源的当前表示

这是不对的——如果你复习的话 RFC 7231 ,您将看到对PUT的响应具有以下描述

行动状态的表示

返回资源的新表示形式是一种边缘情况,而不是默认情况(请参见 Content-Location 标题)。

对于PUT(第4.3.4节)或POST(第4.3.3节)等状态更改请求,这意味着服务器的响应包含该资源的新表示,从而将其与可能仅报告操作的表示(例如,“它工作了!”)区分开来。这允许创作应用程序更新其本地副本,而无需后续GET请求。

也就是说,我建议您对方法令牌的选择进行回顾。PUT和PATCH都支持远程创作语义,即要求服务器使其文档副本看起来像您的本地副本的消息。例如,这就是为什么 PUT 规范对向响应中添加验证器头字段有一系列限制。通用组件可以假设它们知道发生了什么,因为 全部的 资源应该以同样的方式理解这些方法。

但在您的情况下,不能说您是在远程编写集合,因为客户端(和通用组件)没有集合的表示形式,而只有集合页面的表示形式。

如果要与统一接口保持一致,那么

允许远程编写页面,或
放弃暗示远程创作的方法标记

It is okay to use POST 当请求的语义与标准化的含义不太一致时

POST在HTTP中有许多有用的用途,包括此操作的一般用途不值得标准化。