0.1% of people will implement this into their code.
Waste of time.
The HTTP Query Method
81–90 of 136 posts
Re: The HTTP Query Method
#82Earlier quoted context omitted.
I might be misunderstanding something, but it seems the issue isn't really about whether GET can technically carry a body. The deeper concern is that HTTP methods have specific meanings, and mixing those signals can causes confusion and it's nice to have this semantic separation.
The problem is that they are not enforced. You can already have GET requests that modify state even though they are not supposed to. What you are actually doing when making a specific kind of request is assuming the actual properties match the documented properties and acting accordingly. A QUERY seems to be no more than a POST that documents it is idempotent. Furthermore, you should only QUERY a resource that has ad…
> A QUERY seems to be no more than a POST that documents it is idempotent.
This is false.
By design QUERY is both safe and idempotent. In the context of HTTP, safe means "read-only", whereas idempotent means that a method does not introduce changes on the server, and thus many requests have the same effect of posting a single request.
The fact that the semantics of an operation is deemed safe has far-reaching implications in the design of any participant of a HTTP request, including firewalls, load balancers, proxies.
> You might as well name that the “Idempotent-Post” header and then you just issue a POST;
This is outright wrong, and completely ignores the semantics of a POST request. POST requests by design are neither safe not idempotent. You do not change that with random request headers.
Re: The HTTP Query Method
#83Earlier quoted context omitted.
Sending a GET request with a body is just asking for all sorts of weird caching and processing issues.
I get the GPs suggestion is non-conventional but I don’t see why it would cause caching issues. If you’re sending over TLS (and there’s little reason why you shouldn’t these day) then you can limit these caching issues to the user agent and infra you host. Caching is also generally managed via HTTP headers, and you also have control over them. Processing might be a bigger issue, but again, it’s just any hosting infra…
To be clear, it's less of a "suggestion" and more of a report of something I've come across in the wild.
And as much as it may disregard the RFC, that's not a convincing argument for the customer who is looking to interact with a specific server that requires it.
Re: The HTTP Query Method
#84I 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.
And oftentimes some endpoints simply hit the max URL length limit and need a proper body.
I thought we ought to already be using this method. Seems quite fitting for fulfilling GETs with bodies.
Re: The HTTP Query Method
#85Earlier quoted context omitted.
Very timely as I just recently ended up with a URL query string so big that CloudFront rejected the request before it even hit my server.. Ended up switching that endpoint to POST. Would've liked QUERY for that!
I have come across systems that use GET but with a payload like POST. This allows the GET to bypass the 4k URL limit. It's not a common pattern, and QUERY is a nice way to differentiate it (and, I suspect will be more compatible with Middleware). I have a suspicion that quite a few servers support this pattern (as does my own) but not many programmers are aware of it, so it's very infrequently used.
Elasticsearch comes to mind.[0]
The docs state that is query is in the URL parameters, that will be used.I remember that a few years back it wasn't as easy - you HAD to send the query in the GET requests body. (Or it could have been that I had a monster queries that didn't fit through the URL character limits.)
0: https://www.elastic.co/docs/api/doc/elasticsearch/operation/...
Re: The HTTP Query Method
#86Earlier quoted context omitted.
I'm confused - wouldn't idempotent POST be PUT? Isn't the proposed QUERY for fetching semantics?
I think the idea is that POST creates a record (and in theory fails if that record already exists). I guess the commenter above is saying that if you inverted that (fail when the record doesn't exist, return the record if it does) it would be similar to QUERY? Not sure if I agree with that, but PUT's return semantics are a bit vague.. it often returns partial or combined records, or just a 200 OK (with or without a r…
No, I was referencing the example in the article in literally the very first section showing and explaining how POST endpoints are used for fetching data when GET endpoints are too limited. This is literally their motivating impetus for the QUERY request type.
When considered abstractly, POST is just a request body and a response body. This is obviously powerful enough to define any behavior you want; it is just a channel flowing a nearly arbitrary amount of opaque data between the client and server.
However, this kind of sucks because it does not define or constrain the behavior of the client or the server. QUERY says that the server is intended to interpret the request body as fetch parameters and return a response body as the fetched data, and further guarantee that the fetch is safe/idempotent. This is very useful.
My disagreement is that there is no good reason for the client request format to care. You should “POST” to a “QUERY” endpoint. The fact that this endpoint guarantees QUERY behavior is just part of the documented server interface in the same way that certain endpoints may not support PUT. This is a server constraint, not a client constraint so should not change the client transport format.
Requiring a new Client request type to agree with a new Server endpoint type is just unnecessary and mixes up server versus client responsibility and interface design.
Re: The HTTP Query Method
#870.1% of people will implement this into their code. Waste of time.
In the first ten years? Maybe. After that, it might become mainstream.
Re: The HTTP Query Method
#88Interesting 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.
Re: The HTTP Query Method
#89PSA: 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 un…
> please use the IETF Datatracker URL. On my phone, your Datatracker link results in an unreadable mess of a page due to the hard-coded line breaks in the plaintext rendition of the RFC text (making it unreadable in portrait mode) and the huge sticky page nav (causing the content viewport to shrink vertically to almost zero in landscape mode). The HTML page behind OP's link reads just fine. > The best way to view an…
It reads decently in landscape mode, and i’m on a small screen (iPhone se 3rd gen).
Re: The HTTP Query Method
#90Making GET requests have bodies as the norm would also handle this
That ship sailed decades ago. Too much software and middleware expects GET to not have a body and who knows how itll break when you start sending one. Obviously you can do it today and it might work and then randomly break when the code between client and server changes. Adding a new http method is the only way to support something like this safely. If something in between doesn't know what to do with QUERY it can ju…
you're right