Answers:
/records/1;2;3”，因此对此的2xx响应可能会导致他们清除其缓存/records/1;2;3；不净化/records/1，/records/2或/records/3; 代表410响应/records/1;2;3或其他您认为没有意义的事情。records=[1,2,3]to 的正文/delete-requests）并轮询创建的资源（由Location响应的标头指定），以了解您的请求是否已被接受，拒绝或处理中或已完成。这对于长时间运行的操作很有用。另一种方法是将PATCH请求发送到列表资源，/records，其主体包含资源列表以及对这些资源执行的操作（您要支持的任何格式）。这对于快速操作很有用，其中请求的响应代码可以指示操作的结果。可以在不限制REST约束的情况下实现一切，通常的答案是将“问题”转化为资源，并为其提供URL。
因此，批处理操作（例如在此处删除，将多个项目发布到列表中或对大量资源进行相同的编辑）都可以通过创建“批处理操作”列表并将新操作发布到其中来进行处理。
不要忘记，REST不是解决任何问题的唯一方法。“REST”只是一种建筑风格，你不具备坚持它（但你失去了上网的一些好处，如果你不这样做）。我建议您查看一下此HTTP API体系结构列表，然后选择适合您的一种。只要选择其他体系结构，就应该知道自己会遭受什么损失，然后根据用例做出明智的决定。
对于用于在REST Web服务中处理批处理操作的模式，此问题有一些错误的答案？投票太多，但也应该阅读。
DELETE请求，则被请求者和服务器之间的任何内容都将认为正在删除指定URL上的单个资源。查询字符串是这些设备URL的不透明部分，因此无论如何指定API都无关紧要，它们不了解此知识，因此不能表现不同。
DELETE禁止将请求正文与请求一起传递。不要这样 如果你愿意，我会吃掉你的孩子。名词名词名词
如果GET /records?filteringCriteria返回符合条件的所有记录的数组，则DELETE /records?filteringCriteria可以删除所有此类记录。
在这种情况下，您的问题的答案将是DELETE /records?id=1&id=2&id=3。
GET /records?id=1&id=2&id=3也不会意味着“拿到三个记录与ID为1，2＆3”，它的意思是“获取与URL路径/记录？ID = 1＆ID = 2＆ID = 3的单个资源”，这可能是一个萝卜一个画面，一个纯文本包含中文数字“ 42”的文档，或者可能不存在。
/records?id=1和/records?id=2发送两个连续的请求，并且它们的响应被某些中介（例如，浏览器或ISP）缓存。如果Internet知道您的应用程序的含义，那么/records?id=1&id=2就可以推断出缓存可以简单地通过合并（以某种方式）合并已经拥有的两个结果而无需请求原始服务器来返回请求。但这是不可能的。/records?id=1&id=2可能无效（每个请求只允许使用1个ID），或者可能返回完全不同的内容（萝卜）。
id[]=1&id[]=2还是id=1&id=2在查询字符串中表示值数组，该查询字符串都确实表示该值。而且我认为让查询字符串代表过滤器是一种非常普遍且良好的做法。此外，如果允许删除和更新，请不要缓存GET请求。如果这样做，客户端将保持陈旧状态。
我认为Mozilla Storage Service SyncStorage API v1.5是使用REST删除多个记录的好方法。
DELETE https://<endpoint-url>/storage/<collection>DELETE https://<endpoint-url>/storage/<collection>?ids=<ids>ids：从集合中删除BSO，其ID在提供的逗号分隔列表中。最多可以提供100个ID。
DELETE https://<endpoint-url>/storage/<collection>/<id>http://moz-services-docs.readthedocs.io/zh-CN/latest/storage/apis-1.5.html#api-instructions
这似乎是REST约定的灰色区域。
是的，到目前为止，我只遇到过一篇提到批处理操作（例如批删除）的REST API设计指南：google api设计指南。
本指南提到了创建“自定义”方法的方法，这些方法可以使用冒号通过资源进行关联，例如https://service.name/v1/some/resource/name:customVerb，还明确提到了批处理操作作为用例：
定制方法可以与资源，集合或服务相关联。它可以接受任意请求并返回任意响应，并且还支持流式请求和响应。自定义方法应使用HTTP POST动词，因为它具有最灵活的语义。对于性能至关重要的方法，提供自定义批处理方法以减少每个请求的开销可能很有用。
因此，您可以根据Google的API指南执行以下操作：
POST /api/path/to/your/collection:batchDelete...删除一堆您的收藏资源。
If the HTTP verb used for the custom method does not accept an HTTP request body (GET, DELETE), the HTTP configuration of such method must not use the body clause at all,在“自定义方法”一章中说的很有趣。但是 GET accounts.locations.batchGetapi是带有body的GET方法。太奇怪了 developers.google.com/my-business/reference/rest/v4/…–
POST所使用的http方法，并且仅命名了custom方法batchGet。我想Google这样做是为了（a）坚持所有自定义方法都必须遵循的规则POST（请参见我的回答），以及（b）使人们更容易在体内放置“过滤器”，因此您不必对查询字符串进行转义或编码。不利的
https://service.name/v1/some/resource/name:customVerb根据定义不是RESTful的。
我已经允许批量替换一个集合，例如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设计，并且出于生产力和缓存分层的原因。