Hacker News Reader

Comment by hu3 | Hacker News Reader

> DELETE requests now use parameters, rather than form encoded bodies, for their payload (This is in accordance w/ the spec.)

As someone who rarely use DELETE requests, what's the best practice for passing parameters and why?

View on HN

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.

I do this too. And some resources require two DELETE requests - the first with parameters and the second one (after a minimum time) doesn't.

I think this is the relevant bit from RFC 9110:

> 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.

The resource to be deleted should be identified in the URL, so there is no need to pass a body. This is the same for `GET`.

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.

https://cloud.google.com/storage/docs/request-preconditions

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.

Query params.

DELETE cannot have request body, just like GET cannot have a request body.

(Well, it's a syntactically valid HTTP message, but there's no semantic meaning to the body.)

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.

That's why I said:

> (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.

Reply on news.ycombinator.com