Just last month, in June, a new HTTP method was added to the standard
(see RFC 10008).
It's called QUERY and it sits right between the GET and the POST methods.
Semantically it is the same as GET (non-destructive, idempotent, cachable),
but it can also have a request body, just like POST.
I am excited about it because I myself have been facing a problem in the past where this kind of request was necessary but did not exist at the time!
In Prezly I have been responsible for the initial design of the product API. Filtering collections of data was a big part of it. We ended up implementing a proper JSON query language, heavily inspired by MongoDB filtering expressions (why reinventing something, if you can steal ๐).
One of the problems we've faced quite quickly was that sometimes complex filtering queries were too big to fit into the query string limit of a GET request.
The natural solution to that was to change the filtering API to using POST requests, with the JSON query passed within the request body.
That worked well but created problems later when we needed to cache API responses. Specifically, for content requested for rendering in customer newsrooms.
We had to configure the caching layer to cache POST responses, but we could do that only for specific URLs, where we knew it was safe.
Having this new QUERY request method would be a much better answer.
I'm looking forward to it becoming widely supported by the infrastructure of the internet. It will make a difference.
But, as usual, it will also probably take a few years to be fully adopted. Hopefully less than a decade ๐
Cheers ๐