The HTTP Query Method
ietf.org
The HTTP Query Method
1–10 of 136 posts
Re: The HTTP Query Method
#2Making GET requests have bodies as the norm would also handle this
Re: The HTTP Query Method
#3Making GET requests have bodies as the norm would also handle this
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.
Re: The HTTP Query Method
#4We 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.
Re: The HTTP Query Method
#5Making GET requests have bodies as the norm would also handle this
GET is a keep things simple stupid approach to caching. The URL is the cache key plus any headers touched by the vary header. Adding the requirement to vary on the body and understand the body content semantics brings in a whole lot of complexity that GET avoids.
Re: The HTTP Query Method
#6Making GET requests have bodies as the norm would also handle this
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 advertised it is idempotent via the “Accept-Query” header. You might as well name that the “Idempotent-Post” header and then you just issue a POST; exactly the same information and properties were expressed and you do not need a new request type to support it.
Re: The HTTP Query Method
#7Earlier 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…
I'm confused - wouldn't idempotent POST be PUT? Isn't the proposed QUERY for fetching semantics?
Re: The HTTP Query Method
#8A 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.
Re: The HTTP Query Method
#9Yes! 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///, 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.)
Re: The HTTP Query Method
#10Earlier quoted context omitted.
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…
I'm confused - wouldn't idempotent POST be PUT? Isn't the proposed QUERY for fetching semantics?
The existing mechanism to get QUERY semantics is a POST that encodes the “fetch parameters” in the body and the response contains the fetched values. You then out-of-band document that this specific use of a fetching POST is idempotent.
This is literally expressed in the document in section 1: Introduction. They just want to take that POST request and replace the word POST with QUERY which also means the server is intended to assure the request is idempotent instead of needing that documented out-of-band.