关于api：使用REST删除多个记录


Delete multiple records using REST

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

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

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

    • 所有选项都不太理想。

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

    相关讨论

  • 是一个可行的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]的主体POST到/delete-requests)并轮询创建的资源(由响应的Location标头指定)以查明您的请求已被接受，拒绝，正在进行或已完成。这对于长时间运行的操作很有用。另一种方法是向列表资源/records发送PATCH请求，其主体包含要对这些资源执行的资源和操作列表(以您想要支持的任何格式)。这对于快速操作很有用，其中请求的响应代码可以指示操作的结果。

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

    不要忘记，REST不是解决任何问题的唯一方法。"REST"只是一种建筑风格，你不必坚持它(但如果你不这样做，你会失去互联网的某些好处)。我建议你查看这个HTTP API架构列表，然后选择适合你的那个。如果您选择其他架构，只要让自己意识到自己失去了什么，并根据您的用例做出明智的决定。

    对于处理REST Web服务中的批处理操作的模式，这个问题有一些不好的答案？有太多的赞成，但也应该被阅读。

    相关讨论

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

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

    相关讨论

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

    删除整个集合。

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

    使用单个请求从集合中删除多个BSO。

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

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

    删除给定位置的BSO。

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

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

    相关讨论

    This seems like a gray area of the REST convention.

    是的，到目前为止，我只提到了一个REST API设计指南，其中提到了批处理操作(例如批量删除)：google api设计指南。

    本指南提到了"自定义"方法的创建，这些方法可以通过使用冒号来通过资源关联，例如https://service.name/v1/some/resource/name:customVerb，它还明确提到批处理操作作为用例：

    A custom method can be associated with a resource, a collection, or a service. It may take an arbitrary request and return an arbitrary response, and also supports streaming request and response. [...] Custom methods should use HTTP POST verb since it has the most flexible semantics [...] For performance critical methods, it may be useful to provide custom batch methods to reduce per-request overhead.

    所以你可以根据谷歌的api指南做以下事情：

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

    ...删除收集资源的一堆项目。

    相关讨论

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

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

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

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

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

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

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

    相关讨论

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

    1
    2
    3
    4
    5
    6
    7
    8
    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 protected]

    每个值分隔

    & (and sign)

    and Content-Type is text/plain OR text as you wish.

    这将出现在向邮递员发送请求中。

    我收到了来自服务器的回复

    而这些回复来自邮递员看起来像这样的服务器。

    1
    2
    3
    4
    5
    6
    7
    Array
    (
        [first_name] => name1
        [last_name] => name2
        [mobile_no] => 2222222222
        [email_id] => [email protected]
    )