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