"Using GET with a Body works"
Seems like this is going everyone's head. You're not supposed to use GET with a Body, this is a hack, therefore having an explicit method makes sense.
Just because it works, doesn't mean its the right way
The use case of QUERY is because POST conveys non-safe, non-idempotent requests which can potentially modify stuff according to the REST spec. GET requests on the other hand convey retrieval of a resource. However, due to GET requests not having a body, there's a limit to the amount of data you can put in the URL and you also cannot put sensitive data in it.
Additionally, GET requests are meant to be highly cacheable by default while a lot of the QUERY type requests are usually meant more for one-shot access.
QUERY is meant to address these limitations.
Hacky things not working is a feature, not a bug.
Except it doesn't. Some API gateways outright strip request bodies from GET requests to prevent them from being forwarded.
It sounds like most people with the "just use GET" nonsense are far from having any experience in cloud computing.
> Just because it works, doesn't mean its the right way
Will be fun when those see a whole new http verb, I bet that leads to at least DoS by the track record of that company.
https://news.ycombinator.com/item?id=48568502 (4d ago, 173 comments)
https://news.ycombinator.com/item?id=29794838 (4y ago, 125 comments)
So is using QUERY requests for quite some time from now.
One should adhere to Best Practices since one cannot control every device between the app and the user. Best Practice says “GET has no body. QUERY can have a body. If QUERY fails (405), use POST with the body.” And eventually, enough proxies will behave well enough that at least the HTTP bit of the app has a chance of working.
> I've had my fair share of situations where I wished for something like HTTP QUERY.
Using POST instead comes with no drawbacks
I'm not sure QUERY is a great solution, because in the context of a web application absolutely no one enjoys using a page that does not keep its state on refresh, so that really limits where QUERY makes sense, but if you have a case that is not driven by navigation, great.
All in all, I dislike the overall focus on the HTTP method when designing "RESTful" interfaces. If all we're building is, effectively, an RPC, why would the cacheability meta-information be the first thing we specify?
I have a weird feeling. Query body is encrypted by https. So CDN will not be able to cache results. In order to make it work right - whole topology of the internet should be redone. Caching on the backend server will not give any real gains for large scale apps.
CDNs already terminate TLS connections so they can cache GET requests.
* the body may be compressed.
DELETE is intended to delete one specific object, pointed to by a unique URL, not to delete arbitrary objects matching some criteria.
So opensearch also allows you to POST search requests, but those are uncacheable
QUERY would fit here perfectly - it's probably trivial for opensearch to add but it will take some time for clients to catch up.
A whole new method whose semantics don't really fit with the others is.. An odd way forward.
RFC 9110 states:
> [..] content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request [..]
> A client SHOULD NOT generate content in a GET request [..]
You left out the important part.
So much simpler...
Exist stuff (caches, CDN, etc.) could serve private information because the HTTP GET is cached without checking the request contents. The new standard can avoid this because old stuff does not know about HTTP QUERY.
* With the caveat that it's only guaranteed if the server is following the RFC correctly.
It can absolutely be guaranteed. What it can't be is communicated to be safe so browser gonna ask its silly question
For one you would never allow a client to dictate the query. That is a security and validation problem. So you have to deconstruct the query anyway and then rebuild it. That's HTTP APIs 101. Now if the authors of this RFC knew what they were doing they could enforce trust with some sort of JWT like trust mechanism but no they don't bother to define ANYTHING like that. Instead and I will quote this for completeness because it's honestly one of the funniest things I've ever read in an RFC.
> 4. Security Considerations
> It can be used as an alternative to passing request information in the URI (e.g., in the query component). This is preferred in some cases, as the URI is more likely to be logged or otherwise processed by intermediaries than the request content. In other cases, where the query contains sensitive information, the potential for logging of the URI might motivate the use of QUERY over GET.
This. This is just plain baffling to me. The argument is that QUERY replaces GET (it doesn't) so let's shove data into the same place that POST already does because it MAY MAY be logged. Bro the people doing the logging are logging the entire damn thing URI, Header, and Body. What even is this.
And again if they knew their shit they would know that GET has a soft cap of 2,083 characters from the internet explorer days so no one shoves more than that into a url for compatibility and if they do they risk losing data so they use POST anyway. Heck my framework even does JSON post bodies in the POST. And again if you are writing an RFC do your research and use this technical fact as an advantage. Define your own limits and explain why based on existing methodology. It would actually give your RFC some weight.
It doesn't even bother to address query feedback errors like what if the disk says no and writes are locked.
Frankly...... I miss the old days when RFCs where measured in pounds of paper.
Every single SQL server allows a client to dictate the query. Furthermore, not all queries are SQL queries.
SPARQL's standard protocol for sending Queries uses HTTP[1], and yes, of course it allows clients to define the query that it sends over HTTP. HTTP QUERY would be ideal for SPARQL queries. There are also many unprotected SPARQL endpoints that you can use without any authentication [2][3].
[1]: https://www.w3.org/TR/sparql11-protocol/#query-operation
There's usually a reason why the simplest solution that pops into one's head is not "just" used by the people who put a lot more thought into it. Not always, but it can be useful to try to come up with it.