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?

Does this answer your question? [Is an entity body allowed for an HTTP DELETE request?](https://stackoverflow.com/questions/299628/is-an-entity-body-allowed-for-an-http-delete-request) — Patrick, Mar 02 '22 at 19:33
@Patrick: I don't see where that addresses the issue of designing a DELETE REST API that requires a lot of data. It just debates the issue if you can get away with putting data in the body of a DELETE request. But it seems not fully settled and that post is 14 years old. — Jonathan Wood, Mar 02 '22 at 19:36
It *is* settled. `DELETE` is specifically for deleting the entity at the specified uri. If you need a different parameterized operation, use POST with a request body. — Evert, Mar 03 '22 at 00:44

score 2 · Accepted Answer · answered Mar 02 '22 at 19:38

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.

Thanks, that might be the answer. Kind of ugly to me though. — Jonathan Wood, Mar 02 '22 at 19:40
Yeah I definitely hear that. However when it comes to lots of data, whether deletions or exports, most other methods seen to leave room for errors and complexities to creep in. — Robert Hafner, Mar 02 '22 at 19:42
This is probably the cleanest and RESTful solution for this scenario. — Miroslav Holec, Apr 26 '22 at 15:13

score 0 · Answer 2 · answered Mar 03 '22 at 12:17

0

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.

answered Mar 03 '22 at 12:17

inf3rno

24,976
11
115
197

1

RFC 7231: A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request. – Miroslav Holec Apr 26 '22 at 15:15
@MiroslavHolec Thanks! Then my intuition was right. – inf3rno Apr 26 '22 at 16:19

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

2 Answers2