The HTTP QUERY Method specification

I see the need, and good write up, but just use this for the definition of GET body.<p>Nothing in the existing spec prevents GET from having a body, though there isn&#x27;t currently a semantic meaning to it.<p>This would fit perfectly, be more compatible and result in a simpler spec and protocol.

Saw this mentioned by @dragonwriter in the discussion at <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36095032" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36095032</a> but it seemed buried&#x2F;easy to miss there. Also the article that thread is discussing is from 2021, whereas this was just published yesterday.

I seriously doubt the usefulness of this method. If you cannot fit the query into URL, because it has a complex structure, you are likely requesting a significant amount of work from server. In data-rich environments which constantly update that work will likely produce unique results every time the request is submitted, so caching etc may not make sense. To me, this is pretty much the same as making the request via POST. The very special use case where you execute complex queries against static data does not deserve such a change in protocol.

Requiring every proxy and web server to implement their own cache hashing algorithm, especially one that should ignore encoding-specific &quot;non-consequential&quot; parts, sounds like a monumentally bad idea.

I was wondering which versions of HTTP will this be added to<p>Thinking, will it be possible to send HTTP&#x2F;1.1 QUERY requests? HTTP&#x2F;2 QUERY requests?<p>Or will it be for HTTP&#x2F;3 or something even higher?<p>Well the examples given in the document seems to indicate that it will be possible to use with HTTP&#x2F;1.1 even<p><pre><code> QUERY &#x2F;contacts HTTP&#x2F;1.1 Host: example.org Content-Type: example&#x2F;query Accept: text&#x2F;csv select surname, givenname, email limit 10</code></pre>

SQL-like queries in the request body seem like a bad idea, what are the security implications and how do we protect against it?<p>Or will the QUERY method end up with the same fate as GraphQL - wherein it&#x27;s more effective and &quot;secure&quot; in a server-to-server setup and the client only deals with REST.

&gt; Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate.<p>And just like with POST, whether or not this is actually the case in a given API, depends entirely on the server-side implementation.<p>Look, I get it. We want to make rules. Rules are good. Rules define things.<p>But in a world where so many &quot;REST APIs&quot; are actually &quot;RESTful&quot; or REST-ish, or <i>&quot;actually about as REST as a Pelican, but we really liked the sound of the acronym&quot;</i>, I wonder if adding one more rule to the pile is really going to substantially change anything.<p>A majority of APIs don&#x27;t even use all of the existing HTTP verbs, or HTTP response codes for that matter. And every API is free to make up their own rules. I had the dubious pleasure of consuming APIs that required GET with both a body and urlparams, and which returned 200 on error, but with an `{error: {...}}` object in the body. The crown jewel so far, was an authentication system that had me send credentials as multipart&#x2F;form-data, with a PUT request (because you inPUT the credentials, see? Not a joke, that was the rationale given to me by the dev who made it.)

I can&#x27;t wait until this becomes a spec. I wrote a small middleware to cache sql and graphql queries and I implemented QUERY and Cache-Control. Worked great and saved a ton of bandwidth for developing and running reports, as I didn&#x27;t have to worry about caching progress. I just reran the whole job. It was like &lt;50 lines of python to pull it off.

previously it was titled SEARCH. I like query better personally, as it kind of aligns with SQL like requests.<p>Here&#x27;s a great post on it- <a href="https:&#x2F;&#x2F;httptoolkit.com&#x2F;blog&#x2F;http-search-method&#x2F;" rel="nofollow">https:&#x2F;&#x2F;httptoolkit.com&#x2F;blog&#x2F;http-search-method&#x2F;</a> and earlier HN thread- <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36095032" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36095032</a>

It is a little ironic that a new HTTP method called &quot;QUERY&quot; is being created largely to be able to <i>remove</i> the query from the URL.

This seems like it would introduce a tremendous amount of work to solve a problem that basically does not exist. You can just handle your POST request idempotently. We should just live with the semantics we have.

Love it :)

This would be fun to play around with

While you *can* do the same with a GET (include data in the body), it&#x27;s not spec-compliant for servers to parse and interpret this data.<p><a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;978061&#x2F;http-get-with-request-body#983458" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;978061&#x2F;http-get-with-req...</a><p>When designing an API, and if spec compliance is not key, I wonder if client-compliance would become the issue (clients refusing to emit a GET body).