Hacker News new | ask | show | jobs
by darrelmiller 3382 days ago
Yes, we decided to be opinionated and say you can't describe bodies for operations where the spec says bodies have no meaning. The text should be there, but I think the RC0 revision has some formatting issues that is hiding the text.
2 comments
bpicolo 3381 days ago
Isn't that the older spec which has been replaced by new RFCs though? Thought that's what I read earlier this week. RFC 7230-7237 got rid of that expectation it seems?

Imo, a flaw in the earlier spec. It's clearly the case that people have uses for requesting data via JSON, and GET is the only thing that fits expected semantics ATM. Elasticsearch takes json over GET bodies because it just makes sense.

link
davidbiesack 3381 days ago
RFC 7231 4.3.1 GET says

A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

https://tools.ietf.org/html/rfc7231#section-4.3.1

link
bpicolo 3381 days ago
Seems looser. Regardless, it does make sense for a number of applications to have a better query language than query-strings, or base64-nonsense-via-query strings, heh.
link
darrelmiller 3380 days ago
The text is different but the meaning is the same. A GET body must not have an effect on the request/response. i.e. You can have one, but you are not allowed to use it for anything.
link
bpicolo 3380 days ago
That's not how I interpret it. I don't read "has no defined semantics" as "you can't make up your own". All that says to me is that the RFC doesn't explicitly define any semantics.

The other line I would guess is there because in the past the RFC was worded a bit differently, such that there's tech (webservers or whatever) out there that ignores request bodies on GET, so using it may lead to issues using those pieces of tech.

You can really do whatever you want. I'm not a fan of restrictive/pedantic intepretations of the spec, because HTTP is necessarily something that is really up to the developer in every way. Your database sure doesn't care if it's doing a non-idempotent write as a result of a web request that was a PUT.

Spec or not, it makes sense to be able to support a richer query language through the only HTTP verb specified for retrieving data. Just accepting that as something we can't do because some RFCs say this or that is a bit silly, because most apps out there can support it just fine. Elasticsearch is a much better piece of software because it ignored that bit of advice. (And I've had no problems running Elasticsearch through various different proxy layers, so software like nginx /haproxy also don't seem to care if you use a GET request body).

link
silviogutierrez 3381 days ago
I can understand this approach to GET

But how would you, say, bulk delete 5 different resources? I typically send those payloads in the request body of a DELETE request.

link
SideburnsOfDoom 3381 days ago
> how would you, say, bulk delete 5 different resources? I typically send those payloads in the request body of a DELETE request

From the RFC: The DELETE method requests that the origin server delete the resource identified by the Request-URI.

https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

If the ids are in the body, you are not deleting the resource at the URI. I think that for this kind of operation you are better off with a POST.

link