What do you think people will make the Query request body? Most everything will use this for JSON but it could be anything so what other interesting things do you think will go in there? Query 1 + 1 and get 2?
Graphql?
The new HTTP QUERY method explained
91–100 of 179 posts
Re: The new HTTP QUERY method explained
#92"QUERY is just GET" "Using GET with a Body works" Seems like this is going everyone's head. You're not supposed to use GET with a Body, this is a hack, therefore having an explicit method makes sense. Just because it works, doesn't mean its the right way
It sounds like GET with a body is just undefined behavior.
Why not just standardize it? It seems to be a better way than adding a new method.
Re: The new HTTP QUERY method explained
#93Nice, not having bodies on GET has been a pet peeve of mine for a long time. It would be nice to allow bodies on DELETE as well, but that is less of a problem in most cases.
DELETE is idempotent, so I am not sure what the body would do?
Re: The new HTTP QUERY method explained
#94HTTP QUERY was discussed many times in the past here: https://news.ycombinator.com/item?id=48568502 (4d ago, 173 comments) https://news.ycombinator.com/item?id=29794838 (4y ago, 125 comments)
Yes but the author wants to promote his postman replacement
Re: The new HTTP QUERY method explained
#95"QUERY is just GET" "Using GET with a Body works" Seems like this is going everyone's head. You're not supposed to use GET with a Body, this is a hack, therefore having an explicit method makes sense. Just because it works, doesn't mean its the right way
> Just because it works, doesn't mean its the right way Tell that to anybody in the business long enough to decipher someone else's Perl!
It's possible that the slogan "There's one obvious way to do it" as a riposte to "There's more than one way to do it" was more responsible for Python's first wave of success than anything else.
Re: The new HTTP QUERY method explained
#96The other issue with adding a separate supported way to do what people did with GET+body is that we will probably see servers slowly drop support for the GET+body approach when QUERY gets widespread support/usage, and then a ton of other stuff will break.
Unless you're really going to improve things or the existing practices are really too painful, standards should follow convention. Even though GET+body is not handled the same everywhere, it's easier to make that the standard than it is to make a new syntax the standard.
Re: The new HTTP QUERY method explained
#97It's interesting to see additions to HTTP methods as it much feels like the existing ones are set in stone. At least for the time that I have been a developer. I'm curious to see how fast the adoption/support for HTTP QUERY will be. I've had my fair share of situations where I wished for something like HTTP QUERY.
zero. Many libs will/can just request method as a string so you can start coding now > I've had my fair share of situations where I wished for something like HTTP QUERY. Using POST instead comes with no drawbacks
> zero. Many libs will/can just request method as a string so you can start coding now
Not so fast, champ. It matters nothing what your library let's you run away with. What matters is that every single box in the internet between you and the origin server will tolerate, and your pet library doesn't have a say in that.
> Using POST instead comes with no drawbacks
There's a hefty share of ignorance in your comment. Between POST being classified as an unsafe method and the absence of support for cashing, there are plenty of downsides of abusing POST for query requests.
As the RFC was initially proposed by someone from Cloudflare, were you aware that not even Cloudflare support caching POST requests? Their unofficial support for caching POST requests is to create a fake GET request to serve as cache key and use that to cache the response. This is the kind of hacks everyone is forced to go through instead of using something like QUERY
Re: The new HTTP QUERY method explained
#98"QUERY is just GET" "Using GET with a Body works" Seems like this is going everyone's head. You're not supposed to use GET with a Body, this is a hack, therefore having an explicit method makes sense. Just because it works, doesn't mean its the right way
> "Using GET with a Body works" Except it doesn't. Some API gateways outright strip request bodies from GET requests to prevent them from being forwarded. It sounds like most people with the "just use GET" nonsense are far from having any experience in cloud computing.
QUERY won't be supported by them either.
So, change is required. Just change GET to allow for body and move on.
Most of the systems that are blocking GET/body could be easily tweaked to allow it. Today. As is.
QUERY will likely need firmware updates, core engine updates, etc.
Meanwhile, tweaking GET is a rule change.
Re: The new HTTP QUERY method explained
#99This looks like a effort to inject some planned obsolescence in HTTP more than anything else.
Re: The new HTTP QUERY method explained
#100Earlier quoted context omitted.
The whole connection is encrypted by https, the request body is treated the same as the url, the headers or the response. The only unencrypted parts are the IP addresses/ports and the domain name (if SNI without ECH is used). CDNs already terminate TLS connections so they can cache GET requests.
Even past the TLS point (CDNs terminate TLS, so they can read the body) there's a harder problem nobody's solved: to cache a QUERY the cache has to fold the body into the cache key, and there's no standard way to canonicalize a request body. {"a":1,"b":2} and {"b":2,"a":1} are the same query and two different cache entries; whitespace, float formatting, unordered keys all fork the key. GET gets this for free because…
I think the simple approach of using a bitwise comparison will result in satisfactory caching for most applications.