Question

删除多个项目的REST-ful方式是什么？

我的用例是我有一个Backbone Collection，我需要能够一次删除多个项目。选项似乎是：

为每条记录发送一个DELETE请求（如果有可能存在数十个项目，这似乎是一个坏主意）;
发送一个DELETE，其中要删除的ID在URL中串在一起（即“/ records / 1; 2; 3”）;
以非REST方式，发送包含标记为要删除的ID的自定义JSON对象。

所有选项都不太理想。

这似乎是REST约定的灰色区域。

Answer 1

是一个可行的RESTful选择，但显然有你所描述的限制。
不要这样做。中间人将其解释为“在/records/1;2;3处删除（单个）资源” - 因此对此的2xx响应可能会导致他们清除其/records/1;2;3的缓存; 不清除/records/1，/records/2或/records/3;代理/records/1;2;3的410响应，或其他从你的观点来看没有意义的事情。
这个选择最好，，可以RESTful完成。如果您正在创建API并且希望允许对资源进行大量更改，则可以使用REST来执行此操作，但对于许多人而言，确切的方法并不是很明显。一种方法是创建“更改请求”资源（例如，通过将records=[1,2,3]等主体张贴到/delete-requests）并轮询创建的资源（由{{1指定）（）响应标题）以确定您的请求是否已被接受，拒绝，正在进行或已完成。这对于长时间运行的操作很有用。另一种方法是向列表资源发送Location请求，PATCH，其主体包含要对这些资源执行的资源和操作列表（无论采用何种格式）你想支持）。这对于快速操作很有用，其中请求的响应代码可以指示操作的结果。

在保持REST限制的同时，一切都可以实现，通常答案是将“问题”变成资源，并给它一个URL。
因此，批处理操作（例如在此处删除，或将多个项目发布到列表中，或对大量资源进行相同的编辑）都可以通过创建“批处理操作”列表并将新操作发布到其中来处理。 / p>

不要忘记，REST不是解决任何问题的唯一方法。 “REST”只是一种架构风格，你不会拥有来坚持它（但如果你不这样做，你将失去互联网的某些好处）。我建议你往下看这个HTTP API architectures列表并选择适合你的那个。如果你选择其他架构，只要让自己意识到你失去了什么，并根据你的用例做出明智的决定。

Patterns for handling batch operations in REST web services?上的这个问题有一些不好的答案，它们有太多的赞成，但也应该被阅读。

Answer 2

如果GET /records?filteringCriteria返回符合条件的所有记录的数组，则DELETE /records?filteringCriteria可以删除所有此类记录。

在这种情况下，您的问题的答案是DELETE /records?id=1&id=2&id=3。

Answer 3

我认为Mozilla存储服务SyncStorage API v1.5是使用REST删除多个记录的好方法。

删除整个集合。

DELETE https://<endpoint-url>/storage/<collection>

通过单个请求从集合中删除多个BSO。

DELETE https://<endpoint-url>/storage/<collection>?ids=<ids>

ids ：从集合中删除其ID在提供的逗号分隔列表中的BSO。最多可以提供100个ID。

删除给定位置的BSO。

DELETE https://<endpoint-url>/storage/<collection>/<id>

http://moz-services-docs.readthedocs.io/en/latest/storage/apis-1.5.html#api-instructions

Answer 4

这似乎是REST约定的灰色区域。

是的，到目前为止，我只涉及到一种提及批处理操作（例如批删除）的REST API设计指南：google api design guide。

本指南mentions创建“自定义”方法，该方法可以通过使用冒号（例如冒号）通过资源进行关联。 https://service.name/v1/some/resource/name:customVerb，它也明确提到了批处理操作作为用例：

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

因此，您可以根据Google的api指南执行以下操作：

POST /api/path/to/your/collection:batchDelete

......删除一堆收集资源。

Answer 5

我允许批量更换收藏品，例如PUT ~/people/123/shoes其中正文是整个集合表示。

这适用于小型子项集合，其中客户端想要查看项目并删除一些项目并添加其他项目然后更新服务器。他们可以将一个空集合删除所有。

这意味着GET ~/people/123/shoes/9仍会保留在缓存中，即使PUT删除它，但这只是一个缓存问题，如果其他人删除了鞋子就会出现问题。

我的数据/系统API总是使用ETag而不是到期时间，因此每个请求都会遇到服务器，我需要正确的版本/并发标头来改变数据。对于只读和查看/报告对齐的API，我确实使用到期时间来减少原点命中，例如排行榜可以持续10分钟。

对于更大的集合，例如~/people，我倾向于不需要多次删除，用例往往不会自然产生，因此单个DELETE工作正常。

将来，根据构建REST API和遇到相同问题和要求（如审计）的经验，我倾向于仅使用GET和POST动词并围绕事件进行设计，例如： POST一个地址变更事件，虽然我怀疑它会带来一系列问题：）

我还允许前端开发人员构建他们自己的API，这些API使用更严格的后端API，因为他们不喜欢严格的“Fielding zealot”REST API设计，并且通常会有实际的，有效的客户端原因，以及因为生产力和缓存分层的原因。

Answer 6

如果要在RESTAPI的DELETE HTTP方法（例如POST，GET，PUT）中发送多个参数，请尝试以下操作：

DELETE /app/module/test HTTP/1.1
Host: xxx.xxx.x.xx
ACCESS-TOKEN: xxxxxxxxxxxxxxxxxxxxxxxx
Content-Type: text/plain
Cache-Control: no-cache
Postman-Token: 3eabfb52-fdb2-4b05-aefa-b2fb0c53c247

first_name=name1&last_name=name2&mobile_no=2222222222&email_id=try@domain.com

每个值以

分隔

＆（和符号）

，并且Content-Type是 text / plain 或 text 。

This will appear in sending a request to the postman.

我已经收到来自服务器的响应

And these responses came from the server which looked like this on the postman.

Array
(
    [first_name] => name1
    [last_name] => name2
    [mobile_no] => 2222222222
    [email_id] => try@domain.com
)

使用REST删除多个记录

6 个答案:

删除整个集合。

通过单个请求从集合中删除多个BSO。

删除给定位置的BSO。