With a request body you can also rely on all the other standard semantics that request bodies afford, such as different content-types, content encoding. Query parameters are also often considered less secure for things like PII and (less important these days) query parameters don't really define character encoding.

But generally the most important reason is that you can take advantage of the full range of mimetypes, and yes practicality speaking there's a limit on how much you should stuff in a query parameter.

This has resulted in tons of protocols using POST, such as GraphQL. This is a nice middle ground.

Servers have to limit header size as well, since content-length isn't available. Without a bounded header size the client can just send indefinitely.

Also just impossible to read, and url encoding is full of parser alignment issues. I have to imagine that QUERY would support a json request body.

Size can be a very practical concern if your query parameter is e.g. a picture.

Not showing the URL in various logs can be a concern if your query parameters are sensitive.

A picture as an input for a GET seems like a very strange use-case. Can you elaborate?

I do agree on the quirkiness of encoding a bunch of data in the URL. Its nice to decouple the endpoint from the input at a more fundamental level.

Use cases like reverse image search come to mind

Reasons:

  - URI length limits (not just
    browsers, but also things
    like Jersey)
  
  - q-params are ugly and limiting
    by comparison to an arbitrarily
    large and complex request body
    with a MIME type

However, q-params are super convenient because the query is then part of the URI, which you can then cut-n-paste around. Of course, a convenient middle of the road is to use a QUERY which returns not just query results but also a URI with the query expressed as q-params so you can cut-n-paste it.

Query params are also extremely commonly logged all over the place and so putting sensitive information in them is almost always a bad idea.

Of course. The security considerations section does mention this as a feature of `QUERY`, saying that the `Location:` returned by the server should not encode all the details of the request.

However it's also true that q-params effectively form part of the UI. I'm certain you've edited URIs before -- I have, and I know not-so-knowledgeable people who do it too.

Striking a balance here is not easy. With `QUERY` the server can decide how much of the query to encode into the `Location:`, if any of it at all. The server might use knowledge of the "schema" that the query refers to, or it might use the syntax of the query (if it supports indicating sensitive portions), or it might only "link-shorten" the whole query.

This avoid changing the definition of GET. Who knows how many middle boxes would mess with things if you did that because they “know” what GET means and so their thing is “safe”.

Until GET changes.

People aren’t using QUERY yet so that problem doesn’t exist.