How to design DELETE REST API that requires lots of data?

Question

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?

Answer 1

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.

Answer 2

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:

• Do what Robert says and POST a transaction resource instead like DeletionRequest.
• Group the resources you want to delete and DELETE the entire group.
• Do a massive hack and PATCH the collection of resources you want to delete from.