如何设计需要大量数据的DELETE REST API？
我想实现 DELETE REST API。但我需要提供要删除的 ID 列表的选项。该列表可以任意长，并且可能无法容纳在 URL 中。
我知道 POST 支持这一点，但对此和 DELETE 的支持似乎有争议。我想知道其他人是如何处理这个案子的。
如何设计 API 来处理这种情况？
I want to implement a DELETE REST API. But I need the option to provide a list of IDs to be deleted. This list could be arbitrarily long and may not fit within a URL.
I know POST supports this, but support for this and DELETE seems debatable. I wonder how others are handling this case.
How would an API be designed to handle this case?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不幸的是，这是 REST 最大的限制之一，但有一些方法可以解决它。
在本例中，我将抽象出一个新实体 DeletionRequest，并将其与适当的 ID 一起发布或放置。由于它是一个新实体，因此它有自己的休息端点。
这样做的一个很好的副作用是端点和实体可以扩展以支持异步请求。如果您想删除大量数据，您不希望依赖于单个请求中发生的数据，因为诸如超时之类的事情可能会妨碍您。通过 DeletionRequest，用户可以在第一次推送时获取删除请求的 ID，然后使用 GET 请求检查状态。在幕后，您可以使用异步系统（celery、sidekiq 等）来实际删除内容并更新 DeletionRequest 的状态。
当然，您不必走那么远才能开始，但这将允许您朝这个方向扩展应用程序，而无需更改 API。
This is unfortunately one of the biggest limitations in REST, but there are ways around it.
In this case I would abstract out a new entity, DeletionRequest, and have that get posted or put with the appropriate IDs. Since it is a new entity it would have its own rest endpoints.
A nice side effect of this is that the endpoints and entity can be expanded out to support async requests. If you want to delete a ton of data you don't want to rely on it happening in a single request, as things like timeouts can get in the way. With a DeletionRequest the user can get an ID for the deletion request on the first push, and then check the status with a GET request. Behind the scenes you can use an async system (celery, sidekiq, etc) to actually delete things and update the status of the DeletionRequest.
You don't have to take it that far to start, of course, but this would allow you to expand the application in that direction without having to change your API.
URI 是资源标识符，因此我认为 DELETE 不应包含正文，即使您可以在客户端和服务器上执行此操作。您可以在 URI 中发送数据，也可以在 DELETE 之前发送数据。
我在这里看到 3 个选项，但也许还有其他选项：
The URI is the resource identifier, so in my opinion the DELETE should not contain a body even if you can do it with your client and server. Either you send your data in the URI or you send it prior the DELETE.
I see 3 options here, but maybe there are others: