Why some servers do not accept body parameters in HTTP DELETE?

Question

I actually come into this issue, when I am testing an API, which it does not accept a HTTP DELETE with body parameters, but accept query parameters. This is fine, but I am not convinced why body parameters are not handled.

I actually looked in W3C Specification, and it says the following

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.

Source: https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.5

But still, it does not explain why the original design is in this way. Just ask user to be cautious when using body parameters in HTTP DELETE.

I continued searching, and found people suggest query parameters can exactly do the same thing. Why is not a good practice to have an entity body in a HTTP DELETE request?

Yes, I know query parameter work. But why not supporting body parameter? I also come up with someone mentioning RESTful, and think that the URL should identify the resource to be deleted already.

However, some APIs I found on the web, e.g. the one below, seems not able to identify the resources to be deleted from my understanding. e.g. /quotes?side=BUY, which delete ALL buy quotes, but you have no idea which quote you are cancelling.

Definitely, RESTful is just a concept, and is not a rule in HTTP specification which everyone need to obey. So the server can reply properly.

So back to the question, why some server libraries / standard does not accept body parameters in HTTP DELETE?

e.g. server side does not support HTTP DELETE body parameter https://github.com/lukeautry/tsoa/issues/362

e.g. frontend library does not support HTTP DELETE body parameter https://github.com/vercel/next.js/issues/49353

Answer 1

Recommended viewing: REST in Practice, Jim Webber, 2011

So back to the question, why some server libraries / standard does not accept body parameters in HTTP DELETE?

Likely answer: because accepting body parameters at best doesn't do anything useful, and at worse makes a mess.

Structurally, DELETE is a lot like HEAD - all of the information that you need to understand the intent of the request is right there: "please delete the resource identified in the request line".

There's no reason that a message with these semantics would need an entity, and therefore when RFC 2068 specified "[a] message-body MAY be included in a request only when the request method (section 5.1.1) allows an entity-body", only the descriptions of PUT and POST permit a request entity.

The language used was not entirely without its problems, in particular it confuses constraints on the structure of the message with constraints on the semantics - the modern spelling is:

Although request message framing is independent of the method used, content received in a DELETE request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack -- RFC 9110

---

However, some APIs I found on the web...

Yup. I would summarize your findings this way: some APIs on the web are designed by people who have gaps in their understanding of HTTP and/or the REST uniform interface constraint.

And in a reality where there are API -- perhaps even useful ones -- that don't conform to HTTP's uniform interface, library maintainers and standards authors need to make a choice about whether or not to support integration with non-conforming APIs. The problem being, that's not a decision you make on a coin flip, but instead requires evaluating a number of different trade offs.

(That is in itself a broad topic; read up on Postel's Law/the Robustness Principle, and then read up on the number of problems that have been created by trying to follow that principle.)