json - REST:使用一个请求更新多个资源 - 它是标准的还是应该避免的？

Question

一个简单的 REST API:

• GET: items/{id} - 返回具有给定 id 的项目的描述
• PUT: items/{id} - 更新或创建具有给定 id 的项目
• DELETE: items/{id} - 删除具有给定 id 的项目

现在有问题的 API 扩展:

• GET: items?filter - 返回与过滤器匹配的所有项目 ID
• PUT: items - 按照 JSON 有效负载的描述更新或创建一组项目
• [[DELETE: items - 删除 JSON 有效负载描述的项目列表]] <- 不正确

我现在对可以通过 PUT/DELETE items/{id} 轻松访问的 DELETE 和 PUT 操作回收功能感兴趣。

问题:提供这样的 API 是否常见？

替代方案:在单连接多请求时代，发出多个请求很便宜，并且会更加原子化，因为更改要么成功要么失败，但在 NOSQL 数据库时代，即使请求已经发生列表中的更改由于任何原因，处理因内部服务器或其他原因而死。

[更新]

考虑White House Web Standards和 Wikipedia: REST Examples现在使用以下示例 API:

一个简单的 REST API:

• GET: items/{id} - 返回具有给定 id 的项目的描述
• PUT: items/{id} - 更新或创建具有给定 id 的项目
• DELETE: items/{id} - 删除具有给定 id 的项目

顶级资源 API:

• GET: items?filter - 返回与过滤器匹配的所有项目 ID
• POST: items - 更新或创建由 JSON 有效负载描述的一组项目

不支持和禁止对/items 进行 PUT 和 DELETE。

使用 POST 似乎可以解决问题，因为它可以在封闭资源中创建新项目，而不是替换而是追加。

HTTP Semantics POST阅读:

Extending a database through an append operation

PUT 方法需要替换整个集合才能返回 HTTP Semantics PUT 引用的等效表示。 :

A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being returned in a 200 (OK) response.

[更新2]

对于多个对象的更新方面似乎更加一致的替代方法似乎是 PATCH 方法。 Draft RFC 5789 中描述了 PUT 和 PATCH 之间的区别。作为:

The difference between the PUT and PATCH requests is reflected in the way the server processes the enclosed entity to modify the resource identified by the Request-URI. In a PUT request, the enclosed entity is considered to be a modified version of the resource stored on the origin server, and the client is requesting that the stored version be replaced. With PATCH, however, the enclosed entity contains a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version. The PATCH method affects the resource identified by the Request-URI, and it also MAY have side effects on other resources; i.e., new resources may be created, or existing ones modified, by the application of a PATCH.

因此，与 POST 相比，PATCH 可能也是一个更好的主意，因为 PATCH 允许更新，而 POST 只允许附加一些有意义的内容而没有修改的机会。

所以这里的 POST 似乎是错误的，我们需要将我们提议的 API 更改为:

一个简单的 REST API:

• GET: items/{id} - 返回具有给定 id 的项目的描述
• PUT: items/{id} - 更新或创建具有给定 id 的项目
• DELETE: items/{id} - 删除具有给定 id 的项目

顶级资源 API:

• GET: items?filter - 返回与过滤器匹配的所有项目 ID
• POST: items - 创建一个或多个由 JSON 有效负载描述的项目
• PATCH: items - 创建或更新 JSON 有效负载所描述的一个或多个项目

Answer 1

您可以修补集合，例如

PATCH /items
[ { id: 1, name: 'foo' }, { id: 2, name: 'bar' } ]

从技术上讲，PATCH 会识别 URL 中的记录(即 PATCH /items/1 而不是请求正文中的记录，但这似乎是一个很好的实用解决方案。

为了支持在单个调用中删除、创建和更新，标准 REST 约定并不真正支持。一种可能性是一种特殊的“批处理”服务，它可以让您将调用组合在一起:

POST /batch
[
  { method: 'POST', path: '/items', body: { title: 'foo' } },
  { method: 'DELETE', path: '/items/bar' }
]

为每个嵌入式请求返回带有状态代码的响应:

[ 200, 403 ]

不是很标准，但我已经做到了，而且效果很好。