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

您可以修补集合，例如

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 ]

不是很标准，但我已经做到了并且它有效。

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

好吧，有时您只需要执行不符合简单 REST API 的典型方案的原子批处理操作或其他与资源相关的操作，但如果您需要它，则无法避免。

是标准的吗？

没有普遍接受的 REST API 标准，所以这个问题很难回答。但是通过查看一些常用的api设计指南，例如jsonapi.org、restfulapi.net、microsoft api design guide或IBM's REST API Conventions，这些都没有提到批处理操作，你可以推断出这样的操作并不被普遍理解为REST API 的标准特性。

也就是说，google api 设计指南是一个例外，它mentions创建了可以使用冒号通过资源关联的“自定义”方法，例如 https://service.name/v1/some/resource/name:customVerb，它还明确提到批处理操作作为用例：

自定义方法可以与资源、集合或服务相关联。它可以接受任意请求并返回任意响应，并且还支持流式请求和响应。 [...] 自定义方法应该使用 HTTP POST 动词，因为它具有最灵活的语义 [...] 对于性能关键方法，提供自定义批处理方法以减少每个请求的开销可能很有用。

因此，在您提供的示例案例中，您可以根据 google 的 api 指南执行以下操作：

POST /api/items:batchUpdate

此外，一些公共 API 决定提供中央 /batch 端点，例如 google's gmail API。

此外，与 restfulapi.net 上的 mentioned 一样，还有资源“存储”的概念，您可以在其中通过 PUT 一次存储和检索整个项目列表 - 但是，此概念不适用于服务器管理的资源收藏：

存储是客户端管理的资源存储库。存储资源允许 API 客户端将资源放入、取出并决定何时删除它们。商店永远不会生成新的 URI。相反，每个存储的资源都有一个 URI，该 URI 在最初放入存储时由客户端选择。

回答了您最初的问题后，这是尚未提及的另一种解决您的问题的方法。请注意，这种方法有点不合常规，看起来不像典型的 REST API 端点命名方案那么漂亮。我个人没有遵循这种方法，但我仍然觉得应该考虑一下:)

这个想法是，您可以通过端点路径命名方案来区分资源上的 CRUD 操作和其他与资源相关的操作（例如批处理操作）。

例如，考虑一个 RESTful API，它允许您对“公司”资源执行 CRUD 操作，并且您还希望执行一些与“公司”相关的操作，这些操作不适合通常与 RESTful api 关联的面向资源的 CRUD 方案——比如你提到的批量操作。

现在，您可以区分以下各项，而不是直接在 /api/companies 下方（例如 /api/companies/22）公开您的资源：

/api/companies/items – 即公司资源的集合

/api/companies/ops – 即与公司资源相关的操作

对于 items，应用通常的 RESTful api http-methods 和 resource-url 命名方案（例如，如所讨论的 here 或 here）

POST    /api/companies/items
GET     /api/companies/items
GET     /api/companies/items/{id}
DELETE  /api/companies/items/{id}
PUT     /api/companies/items/{id}

现在，对于与公司相关的操作，您可以使用 /api/companies/ops/ 路由前缀并通过 POST 调用操作。

POST    /api/companies/ops/batch-update
POST    /api/companies/ops/batch-delete
POST    /api/companies/ops/garbage-collect-old-companies
POST    /api/companies/ops/increase-some-timestamps-just-for-fun
POST    /api/companies/ops/perform-some-other-action-on-companies-collection

由于 POST 请求不一定会导致创建资源，因此 POST 是在这里使用的正确方法：

POST 方法执行的操作可能不会产生可由 URI 标识的资源。 https://www.rfc-editor.org/rfc/rfc2616#section-9.5

据我了解 REST 概念，它涵盖了通过一个请求更新多个资源。实际上这里的技巧是假设围绕这些多个资源的容器并将其作为一个资源。例如，您可以假设 ID 列表标识包含其他几个资源的资源。

在那些examples in Wikipedia中，他们还谈到了复数形式的资源。