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.

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.

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

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.

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.

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

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.

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