I've stared at enough http where the only difference to me is
GET /foo HTTP/1.1\rnHost: example.com\rn\rn{"foo":"bar"}
POST /foo HTTP/1.1\rnHost: example.com\rn\rn{"foo":"bar"}
QUERY /foo HTTP/1.1\rnHost: example.com\rn\rn{"foo":"bar"}
If it's a possibility that potential clients might refuse to do something like a GET with a body...don't use that as part of your api. Or make the endpoint respond identically to a GET with a body as a POST with a body. Similarly if you're working in a http server framework that makes such a thing difficult.
At the end of the day, I care a hell of a lot more about how well the api is documented than I do about any of it's particular semantics.
> From an implementation point of view, the difference between a POST, GET, and QUERY with a body is...trivial
That said, I'm sure you're right, and there are proxies that don't support a GET with a body. It's an inadvisable thing to implement if there's a chance that your clients may not be able to support it. It's also really easy to just send a POST request with a body instead.
Where I get exhausted is when people start complaining that POSTing a body for something like a search query isn't restful. No, it's not, but it's not worth a heck of a lot of discussion either. In that respect, I'm happy that QUERY is being added, so it can hopefully resolve the distaste that the dogmatic experience. But that's really the only thing that makes me excited about it. Other than hushing the dogmatic, it doesn't really add much value.
In the absence of QUERY, the only way to do large queries is by POSTing them. Anyone who complains that that is not RESTful can go get in the time machine and implement QUERY in 1993.
At the end of the day, I care a hell of a lot more about how well the api is documented than I do about any of it's particular semantics.