REST：用一个请求更新多个资源--这是标准的还是要避免的？

Question

一个简单的REST API：

• get:items/{id}-返回具有给定id的项的说明
• put:items/{id}-更新或创建具有给定id的项目
• 删除：items/{id}-删除具有给定id的项目

null

问题：提供这样的API是常见的吗？

备选方案：在单连接的时代，多个请求发出多个请求是便宜的，而且工作起来更加原子化，因为一个更改要么成功要么失败，但是在NOSQL数据库的时代，列表中的更改可能已经发生了，即使请求处理在内部服务器或其他任何原因中消失了。

[更新]

• get:items/{id}-返回具有给定id的项的说明
• put:items/{id}-更新或创建具有给定id的项目
• 删除：items/{id}-删除具有给定id的项目

顶级资源API：

• 获取：项目？筛选器-返回与筛选器匹配的所有项目ID
• post：items-更新或创建一组由JSON有效负载描述的项

其中PUT方法需要替换完整的集合,以便返回HTTP语义引用的等效表示PUT：

一个给定表示成功PUT将意味着随后对同一目标资源的GET将导致在200(OK)响应中返回一个等价的表示。

[UPDATE2]

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

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

一个简单的REST API：

null

null

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 ]

不是真正的标准，但我做了它，它的工作。