The HTTP Query Method

PSA: When posting an RFC or (especially) an RFC-draft, please use the IETF Datatracker URL.

For example, this one is: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-met...

The best way to view an RFC, IMHO, is to use the "htmlized" format: you can view and compare different versions, view errata for a formal RFC, and go back to Datatracker at any time.

Also, the Datatracker URL is version-insensitive, so unlike the pure HTML format, it will not be stuck on draft-14 forever.

Interesting that instead of just allowing GET with body the proposal went with a new HTTP method. I wonder if this would delay the support by proxies and other middle boxes. It seems supporting body would be easier than a new method.

I can’t wait for QUERY to become an official RFC.

It's felt quite awkward to tiptoe around the existing spec when building features that retrieve data; we've had to either use POST to keep sensitive filter criteria out of http logs or just create a usually massive URL-encoded query string.

At this point I’m infamous in my company for complaining about how something should have been done with a QUERY verb but it hasn’t been approved yet.

The cases tend to look like this: - An endpoint was implemented as a GET endpoint, since it’s for getting data, with the search terms in the query parameters. The search term got too long, breaking a critical behavior in production environments. - An endpoint was implemented as a POST endpoint, despite it being an idempotent query for data, since the request body is too large to fit in query parameters. New employees repeatedly come in and are confused why it’s not a GET endpoint, or why it doesn’t modify anything.

A couple of quick observations and comments after skimming through this (some of these are mentioned or hinted at in the RFC).

With HTTPS used almost everywhere, using this QUERY method (when standardized) could prevent bookmarking specific “GET” URLs if the developers thoughtlessly replace GET everywhere with QUERY.

One of the advantages of GET is the direct visibility, which makes modifications simple and easy for almost anyone (end users, testers, etc.).

The larger question I have is who will choose to adopt it sooner, with web servers, web application frameworks and web browsers in the mix.

As inefficient as encoding everything into the URI is, I really enjoy being able to bookmark and share specific filter configuration. More than one I've seen some sites with UI so bad, that manually editing the url is the easiest way to get it to do what i want.

Yes! This sounds like a great idea to me. It does have some trade-offs, but I think we would've been better off with this than ever having put queries in the URL in the first place. Rather, if it made enough sense to have some data in the URL itself, it would be better if it could actually be in the path, to distinguish it as a distinct resource. I think there are many reasons why this didn't work out that way but I also think those reasons are mostly historical. I would prefer things like /map/<lat>/<long>/, for example. I don't want to go as far as to say that query parameters were entirely a mistake, but there's nothing they do that couldn't be done otherwise, they just offer a convenient place to delineate unstructured data in a URL that you could then copy around. Sometimes moving that to the path would be awkward (unstructured path elements does exist on the web, but it's weird to do) but often times it would just be better to not have it at all. Don't need UTM codes in my URLs in the first place, and I don't think every single parameter on the page should be in the URL. (If you really wanted to pass someone a saved search full of complex queries, it would be less cumbersome to have a specific URL for saved searches anyhow, in my opinion.)

Obviously query parameters are not going anywhere, but if this achieves enough adoption there is a future down the road where we can stop using POST for any query that wants a payload, without needing to change every single HTTP client in the world. (Many of them can already understand custom methods and treat them basically like posts.)

Making GET requests have bodies as the norm would also handle this

Does anyone know what blocks something like this being accepted? I’ve had my eye on this for ages and have had to work around its lack multiple times, so just curious what the hold up could be.

It’s rare that I have a project that justifies the full DDD treatment, but one of the great ideas from it that stuck with me was command/query separation, where you separate out queries, which can be mangled agglomerations of objects for reporting and lists, from commands, which drive your business logic.

I love the idea of a separate verb. It always felt like get is just not quite enough.

For the experienced devs. May I ask why would one use POST for everything?

I encountered a codebase with only POST for all operations, given my lack of knowledge in this area, I am not sure why one would choose POST only over the standard set of GET, PUT, POST, DELETE, etc.

0.1% of people will implement this into their code.

Waste of time.

How does one share the search results with the url to the page with this query method?

First impression was "umm... I don't even use SEARCH yet." Then realize this is actually SEARCH method but renamed and more generalized.

I anticipate this will be used by UI frameworks to transmit a very long list of item ids selected by the user using check boxes. Which will cause suffering to the backend devs dealing with relational databases

We already have POST, PUT, and PATCH that do the exact same thing. Why not have another version of GET that looks the same as POST and is subject to personal interpretation.

FYI: QUERY is for GET requests where the query string make the URL too long. It does this by sending a body like POST.

In the past, POST meant you were sending a body, and GET meant you received a body. And the people got religious about a pseudoacronym called REST.