I tend to make DELETE work without parameters, but allow them in the body (JSON) for non-essential but helpful options. And example is allowing a flag to override delete protections. I doubt this is a “best” practice but I’ve never had a problem with it, or been asked to change it for compatibility.
> A client SHOULD NOT generate content in a DELETE request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.
By way of analogy with POSIX, `cat` (GET) and `rm` (DELETE) both just take a file path, whereas writing or overwriting a file (POST/PUT) also require something (a request body) to write.
This is how I've used DELETE. Something like DELETE /users/{uniqueUserId}. In ~10 years of building CRUD apps I don't think I've ever sent a body or query params with a request.
Some tools let you pass a parameter to indicate that you only want the request to take effect if the requested resource is in some specific state. For example, Google Cloud Storage uses headers to allow you to set preconditions that must be met before the action takes place. For DELETEs you can use this to say "delete this resource but only if its generation (sort of a timestamp) is exactly $foo", where $foo is the generation last known to the client.
What about where you're not just deleting a single entity by id? Like, for instance where a user can bulk select multiple items and then choose to delete them all (like email for instance), or maybe deleting by criteria, like "delete all Entities created before time X"
My gut says I would use query params though I typically stick with 1 action effects 1 record. I can't recall any specific times when I built bulk item management into an app but I'd say that's a personal preference on my end.
Question: what is the proper verb to use with a query? I always thought of it as a GET and passing the query via the body. You are GETting information, rather than trying to add information.
For that matter I've never quite figured out when to use POST vs PUT. POST doesn't feel right for a query.
DELETE and GET can have bodies, the spec is just vague about it. Elasticsearch commonly uses request bodies for GET, treating it identically to POST. It's not always regarded as a good idea, but it does work.
> (Well, it's a syntactically valid HTTP message, but there's no semantic meaning to the body.)
To quote RFC 9110:
> Although request message framing is independent of the method used, content received in a GET 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 (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.
For this reason, Elasticsearch also accepts queries as POST.
As someone who rarely use DELETE requests, what's the best practice for passing parameters and why?