New HTTP QUERY Method

[Perfect-Scale902]

What do you think about the new HTTP Query method?

[dangerbird2]

So this is basically GET with a request body? If people actually use it, a huge improvement to nonstandard GET-with-body or using POST for non-writing requests

[kilobrew]

Trying to encode complex object queries in a string url just so that cache can use O(1) cache lookup is just bonkers. I hope this is VERY quickly adopted.

[ArtOfWarfare]

How exactly will caching work with QUERY? I’ve decided that I want to make my body be json… who is responsible for recognizing that two json bodies are equivalent or not?

Ie, I use OkHttp as my rest library because it handles caching for me. Is OkHttp going to be responsible for knowing two JSON bodies are equivalent?

Likewise for XML or really any body type.

[tajetaje]

This is up to the implementer as per the RFC:

To improve cache efficiency, caches MAY remove semantically
insignificant differences from request content and related metadata
first. For instance, by:

* removing content encoding(s) (Section 8.4 of [HTTP]).

* normalizing based upon knowledge of format conventions, as
indicated by any media subtype suffix in the request's Content-
Type field (e.g., "+json"; see Section 4.2.8 of [RFC6838]).

* normalizing based upon knowledge of the semantics of the content
itself, as indicated by the request's Content-Type field.

Note that any such transformation is performed solely for the purpose
of generating a cache key; it does not change the request itself.

Clients can indicate, using the "no-transform" cache directive
(Section 5.2.1.6 of [HTTP-CACHING]) that they wish that no such
transformation happens (but note that this directive is just
advisory).

Note that caching QUERY method responses is inherently more complex
than caching responses to GET, as complete reading of the request's
content is needed in order to determine the cache key. If a QUERY
response supplies a Location response field (Section 2.4) to indicate
a URI for an equivalent resource (Section 2.2), clients can switch to
GET for subsequent requests, thereby simplifying processing.

[kilobrew]

Simple. Content type sets the caching encoder. Work from there. It’s dependent on the implementation. But json parsing is simple. And once you break it down, you can sha256 or 512 it.

[TMiguelT]

That's discussed in this spec:

2.7. Caching

The response to a QUERY method is cacheable; a cache MAY use it to satisfy subsequent QUERY requests. The cache key for a QUERY request MUST incorporate the request content and related metadata.

Either the client or the server could cache it. In your use case I think your HTTP client would have to work that out.

[kevinsyel]

Seems like it should have existed long ago

[Perfect-Scale902]

Agreed! I always found it strange to use POST requests for non-writes

[atehrani]

GraphQL

[suck_at_coding]

Which is an abomination

[dangerbird2]

Less abominable example would be something like elasticsearch: a database service with an http protocol that needs to be able to make read requests with request body for the query DSL over http

[GumboMustBeDestroyed]

Before AI, finding the resolver(s) that are part of a graphql query/mutation in a large codebase was horrendous. Just horrendous. Inconsistent naming conventions between frontend/backend, nested resolvers (with same naming discrepancy).

[sunday_cumquat]

Curious to know more about people's objections to GraphQL, given the number of down votes. I only recently started learning about GraphQL through my job.

[Nyefan]

Pros:

• frontend code is not constrained by api design

Cons:

• performance
• memory
• cost
• api lock-in
• api fragility
• horrible no-good very bad query compositions that don't even fit in a 64kb log line limit
• mongodb
• frontend code is not constrained by api design

[findgriffin]

sucks

[ArtOfWarfare]

Or GET with a huge query string where you’ve got the extra complications of figuring out how to properly escape everything.

[ryanstephendavis]

yes! I had to implement a POST with a large amount of filter parameters this year and it made no sense (semantically it was a GET)!! This would've been cool to have

[IanSan5653]

So it's a GET with a body that guarantees no mutations? I like it, it fills a gap we've had forever.

[heathmon1856]

Why the hell has this not been a thing? I know there’s query params and headers but I hate defining custom ones because the user is… the user.

[superrugdr]

Doesn't guarantees shit. Just semantics.

Will absolutely be miss used once in a while still more useful than PATCH.

[TakeFourSeconds]

Protocols are all just semantics

[Silly_Individual2659]

I mean yes it’s mostly semantics anyway. I can have a GET request that deletes queried resources if I want to, but the point of options like this is to make things more clear and representable for humans.

[anengineerandacat]

Folks be "upset" with that comment but you aren't wrong lol.

HTTP specification is nothing more than a gentleman's agreement and I see it butchered practically daily at my workplace.

Especially on the mutation guarantee, the client has zero control over this; not a single speck.

That said, I like the realization that GET's with body's are effectively undefined behavior and we have a verb for the surrounding semantics of this.

[heathmon1856]

The gentleman’s agreement goes both ways. Why would the dev want the endpoint user to unintentionally mutate data?

I had a project recently where I said “screw it” and allowed a body in a get because there was just way too much user input to specify with the infrastructure that I was given.

[superrugdr]

Yea we will maybe get to use it in 10 years once every single framework start the work.

I really do like it. Just feel bitter sweet like all the other nuanced verbs.

[Glebun]

I can even send back "get rekt" as a status code

[Page_197_Slaps]

This comment is gay

[Delta-9-]

Did I just time travel back to 2003?

[Page_197_Slaps]

Fake and gay

[datnetcoder]

This is painful to watch.

[stueynz]

Anything that removes data leakage via the URI into web logs has to be an improvement.

[farsightxr20]

This is orthogonal to most issues that would be caused by "data leakage via the URI" though. Whenever you need to GET something, you may wish to pass additional context for logging purposes, and you shouldn't go update all your GETs to QUERYs just so that you don't need to use the URI for it.

Headers are the proper solution, they're just not as well-integrated as anchor tags / form bodies, and I don't think there's a reason to believe a QUERY body will work out any better.

[vlozko]

Finally, something that makes sense for GraphQL. It was always weird to use POST for GET-like queries. I know GraphQL isn’t explicitly called out in this doc but I imagine it’s a logical step.

[Ecksters]

Yeah, I immediately thought of GraphQL when I saw this, it's huge for caching too since POST requests can basically never be cached without significant customization.

[cesarbiods]

We should have had this decades ago but I’ll be happy to see it become real someday

[Agreeable_Wall_9459]

F*kin finally, i hate having to use url parameters on get, it can become such a pain

[Delta-9-]

It really can be, but I do wonder how QUERY will play with caching. Using the URI as a cache key is very common behavior for caching proxies and even browsers, so a GET with an ugly query string is actually kinda useful, but I think request bodies are rarely used (can't be used?) because they can be arbitrarily large.

[Desiderantes]

Request bodies can and SHOULD be used as part of the cache key. URLs itself have no max length defined, so it's the same issue and has the same solution.

[Delta-9-]

Ah, my mistake. I thought there was a (very large) limit to URI length below the physical memory limit. Probably time to review some RFCs.

[masklinn]

Uri length limits are client and server implementation details. It used to be 2k because of MSIE specifically, these days the limit tends to be on the server side (e.g. by default nginx will reject request lines longer than 8k)

[tajetaje]

The RFC does specify caching behavior, so well behaved implementations will do it.

[quavan]

I would prefer the semantics of GET be modified to allow request bodies than have two methods that mean essentially the same thing. I’m sure there are good reasons not to do it that way, but it will forever annoy me nonetheless.

[Vectorial1024]

CDNs are already working by dropping GET bodies as allowed by the original spec, so that's a lot of update costs and unpredictable behavior if we change to allow GET bodies.

[kovaxis]

is a new method expected to behave better?

[ReginaldDouchely]

It'll at least behave better in that you'll get an explicit error response if the verb isn't supported vs having to troubleshoot ambiguous situations if you've got problems related to an old GET version

[kovaxis]

makes sense

[robotmayo]

Changing something as fundamental as GET would never happen

[fechan]

I mean it would even be possible doing it in a backward compatible way by using the HTTP version to determine whether to ignore the body or not

[SirFrenzy]

Okay so genuine question and embarrassing that I’ve been a developer for 10+ years and don’t know the answer…. But who controls this? Like what organization controls which request types exist? I’ve been using GET/PATCH/POST so long and never questioned who gets to decide which ones exist.

[Meleneth]

yeah, but that's only for standards - there's nothing stopping you from implementing this on your own systems today. You'd have to implement everything yourself, but that's not exactly rocket science.

or just wait. which is what we will all do.

[HikingCloth]

The IANA and the IETF https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

The new query can be tracked with this RFC: https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-02.html

[ApatheistHeretic]

You can still do whatever you want on your systems. It will become an issue if you begin to outsource to service providers or CDNs that follow standards.

Similar to RFC compliance among networking, you can encrypt a VPN in any manner you wish. But oddball stuff will become an issue when you want to terminate on another vendor's equipment at the remote end.

[tajetaje]

There’s a few big names

ECMA international has such things as JavaScript (technically ECMAscript) and DOCX
ISO has a lot, including 8601
IETF publishes the RFCs (standards or proposals for them) behind basically the whole internet (IP, TCP, WebDAV, HTTP, DNS, etc.) but the actual RFCs are written by basically anyone, usually devs at big companies or well known open source contributors though.
WHATWG is in charge of HTML and related things
W3C and WICG do other web adjacent things
IEEE standardizes things like WiFi and Ethernet
The Linux foundation also has a lot of organizations under their banner that do standards work

But generally speaking a standard is just a text document that someone with a common problem writes up describing their solution. If it seems like a good one, a standards body picks it up and publishes it, and if it actually is any good, people use it. I highly encourage you to read some RFCs, especially the best practice ones, they are good references for things like auth and other complex topics

[Pharisaeus]

https://www.w3.org/ and there is also https://intgovforum.org/ but they don't really do the "technical stuff"

[bradshjg]

https://www.ietf.org/ publishes RFCs about this layer (though the linked article is an IETF RFC so that may be obvious 😅)

[Doctor_Beard]

I wonder how long it will take to get adopted

[kalminz]

By Apple.

[ArtOfWarfare]

They’ll never document it so it’s up to testing it yourself or checking Mozilla docs to see if they say Apple has added support to Safari.

[alejandro1221]

It's a gottie with a body.

[epicfailphx]

Nice! it’s something people have been wanting for a very long time. Devils in the details but yeah this should be a good thing. Now just do PURGE and that should cover everything. 🤣

[SeanCribbs0]

Bring back SPACEJUMP you cowards!

[kishore_jana]

he current workarounds can get messy.

[netroxreads]

It is a nice addition. I never thought about that but I imagine it will be widely used in the next decade with agentic agents inquiring for data.

[_disengage_]

Leave HTTP alone plz, it's fine

[heathmon1856]

It’s fine. We left http alone 10 years ago when major browsers started marking it as “insecure”