Finally, the spec is crystal clear that message bodies on GET requests are not illegal.
The reason I can think of for sending a payload in a GET is if the data you wanted to send in a query string is too large.
It also defeats caching and any other reasons why you would want to use GET over some other http requests.
I would argue that the only reason left why you would use GET for that, is because it's aesthetically pleasing.
Not all systems support practically unlimited URI payloads[0]. In the past, this forced either contorsion (gzipping URI payload) or piping everything through POST.
For instance, let's say you've built a music identification system, people can send in files and get information about the file's data. This is a purely readonly request, the backend just uses its information to identify the file and fetch whatever data and metadata on the file's content it has. But historically there was no choice but to route it via a semantically unsuitable POST.
[0] Apache defaults to 8190 bytes, IIS to 16384, Safari and Firefox support >100k but MSIE is limited to 2048
It does not break caching.
Instead of just using the URL as the caching key, use URL+body. Same URL and same body = same response.
Well, except that since the body isn't defined as having semantics that determine the response, an cache based on the HTTP protocol spec has no reason to do that.
That said, I POST my search params to Elasticsearch anyways.
> Does that not violate REST principles?
Most attempts to impose semantics on GET bodies would violate REST principles as well as breaking HTTP (given that GET responses are cacheable and the body is treated as not relevant to the response.)