Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The new HTTP QUERY method explained

kreya.app

Post reply on HN
Print view View original

121–130 of 179 posts

Re: The new HTTP QUERY method explained

#121

Post by nesarkvechnep »

theowaway213456 wrote: post #114
nesarkvechnep wrote: post #112

I still don't get the need for QUERY. One can create a search or filter resource with a POST request and then query it using GET. As a bonus, creating a resource allows it to be shared and cached.

Obviously the approach you mentioned has the downside of two server round-trips being necessary while the QUERY request only requires a single round-trip. Not to mention the two-request approach adds more complexity to both clients and servers, as it mandates that both the client and server have to physically create and manage those resources.

Obviously, yes, but is it simpler to add a new HTTP method and add support for it everywhere?

Re: The new HTTP QUERY method explained

#122

Post by Yokohiii »

topham wrote: post #101
unilynx wrote: post #11

Earlier quoted context omitted.

Elastic/Opensearch uses GET requests with a body for search, which is complicated or forbidden (not exactly sure) with the HTTP spec. Not all HTTP clients are willing to submit a body with a GET. So opensearch also allows you to POST search requests, but those are uncacheable QUERY would fit here perfectly - it's probably trivial for opensearch to add but it will take some time for clients to catch up.

Fixing GET would be easier. And yes,it would be fixing a flawed interpretation of what should be implemented.you are, by definition GETting something. Tools dropping body from GET by default are violating the spec today. Rules configured to drop it are just that, temporarily configured constraints readily modified. Adding QUERY will make it unpredictable in effectively the same manner as GET/body. It'll take even lon…

> Fixing GET would be easier.

I disagree. I think the adoption (or dismissal) of QUERY will show.

First thing that comes to mind is that the idempotency of GET resources are easy to handle. URL's have a fixed size, they can be efficiently hashed, cached and are unambiguous about how they serve this purpose.

It is unclear how the ecosystem will deal with the QUERY requirements. It's easy for apps, but browsers, http caches and servers will take some time to figure out solutions.

Fixing GET would have the same amount of uncertainty in addition to the need to keep current expectations valid. It's not easier, it's harder.

Re: The new HTTP QUERY method explained

#123

Post by wseqyrku »

8-prime wrote: post #7

It'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.

This is why there's another method. It's easier to communicate 'QUERY method support' rather than get-with-a-body-no-not-the-one-that-is-unspecified-it-is-accepted-with-slightly-different-semantics-now-EOF.

Re: The new HTTP QUERY method explained

#124

Post by mekdoonggi »

austin-cheney wrote: post #119

It blows my mind that people are invested in this. HTTP is a 35+ year old text-based protocol. Its becoming the COBOL of digital transmission. Just as one example, among many, you could try WebSockets (or some other similar protocol) and then push anything over it. Your message could be plain text, JSON, binary, whatever. Web Sockets and protobufs are bidirectional (full duplex) too.

WONIBDFI (whether or not it's broke, don't fix it)

Re: The new HTTP QUERY method explained

#125

Post by Yokohiii »

0x073 wrote: post #81
IshKebab wrote: post #47

What are the chances sites start using this to prevent sharing links...

With some post websites (banking) and spa already present.

Unironically QUERY seems to me a "quality of life" feature for the SPA world and the ultimate legitimation to kill link sharing. It is too hard to keep links and app state consistent, so lets just drop it.

Re: The new HTTP QUERY method explained

#126

Post by Vosporos »

maxloh wrote: post #92
ramon156 wrote: post #37

"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.

A lot of un-updateable software out there that strip the body. Especially when the companies behind it doesn't provide support anymore.

Re: The new HTTP QUERY method explained

#127

Post by Ghoelian »

topham wrote: post #104
dxdm wrote: post #66

Earlier quoted context omitted.

The article also addresses why this is not the chosen solution. It's pretty much the first one you'd think of: all kinds of existing software (that can be between client and server and out of their control) already handle GET bodies in all kinds of incompatible ways, because the existing standard says they're meaningless and "shouldn't" be included. The idea is to not break people's stuff, so they don't rugpull the e…

So, I need to update all the tools to support QUERY, or I need to update all the tools to support GET/body. So, either way, I need to update all the tools. Just fix GET.

The point is that if you do that, you end up with lots of undefined behaviour in existing software that has not been patched yet.

If you make it a whole new request method, existing unpatched software should just respond with "Method not allowed".

Re: The new HTTP QUERY method explained

#128

Post by Yokohiii »

CodesInChaos wrote: post #100
vshulcz wrote: post #88

Earlier quoted context omitted.

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.

Can you elaborate? Do you think the noted issues are non-issues that should be fixed in applications? Which would require a new standard to create stable JSON outputs, which is just one use case that can fail right now.

Re: The new HTTP QUERY method explained

#129

Post by lightningspirit »

austin-cheney wrote: post #119

It blows my mind that people are invested in this. HTTP is a 35+ year old text-based protocol. Its becoming the COBOL of digital transmission. Just as one example, among many, you could try WebSockets (or some other similar protocol) and then push anything over it. Your message could be plain text, JSON, binary, whatever. Web Sockets and protobufs are bidirectional (full duplex) too.

The internet is complex, and you have tons of protocols that are not well supported. TCP/HTTP are well supported by proxies and have well-defined, stable specs, which also help with caching, throttling, etc.

Just because it's old doesn't mean it is worse than alternatives, most likely it is quite the contrary.

Re: The new HTTP QUERY method explained

#130

Post by lightningspirit »

nesarkvechnep wrote: post #121
theowaway213456 wrote: post #114

Earlier quoted context omitted.

Obviously the approach you mentioned has the downside of two server round-trips being necessary while the QUERY request only requires a single round-trip. Not to mention the two-request approach adds more complexity to both clients and servers, as it mandates that both the client and server have to physically create and manage those resources.

Obviously, yes, but is it simpler to add a new HTTP method and add support for it everywhere?

Because HTTP is stateless by definition, you now need to support persistence (state) on the server side whenever you want to run a slightly different query, which contradicts the preamble.

I understand the confusion around GraphQL's cached/persisted queries, but this is not the intention of HTTP.

Post reply on HN