Hacker News Reader

Comment by comfypotato | Hacker News Reader

The link to the new query method [1] intrigued me. Could this, if widely adopted, make GraphQL obsolete? (Or am I admittedly ignorant as to exactly what they each do?)

[1] https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-m...

View on HN

If everything works out, grapnel could use it and queries would be cacheable by generic http caches. A lot would need to happen to make that work, though. The immediate motivation is to get an alternative to people who want to put a request body on GET.

Graphql. I love autocorrect.

A sailor must have invented it.

IIRC query is just a method that you'd use for your GraphQL route. It doesn't actually have any querying system defined in the spec (See final sentence here https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-m...)

The main focus of HTTP 2 and 3 was apparently performance, and hardly any of the other fundamental issues of the protocol. It's nice to see that some work is put into something like QUERY as well, which improves HTTP as an API protocol (REST) - although the motivation appears to be performance again and I always have mixed feelings when I see the term "idempotent" in a context that likely involves database systems. Too often, such requests do have side effects of some kind and preventing request retries throughout the stack isn't easy.

Definitely not performance, QUERY is an improvement/hackfix. Browsers have a cap on size of the request headline path (used to be very small for IE7), and server software also tend to cap the size of it, as a security mitigation (smth like max header size, similar to what happens with cookies). For this reason, technologies such as elasticsearch or graphql, which allow for quite large query defs, use POST and fit the query in the body instead, which is not bound to the same limitations.

Semantically, such queries are cacheable, but the request being POST, intermediate edge proxies or CDNs won't cache the request. This means clients pay the penalty every single time. Moreover, browsers can't have url-based history with such solutions, as POST requests can't "go back".

So QUERY fixes this. Semantically. Now you have to build support in middle boxes for it, and browsers must support it as well.

As far as I know, GET and DELETE requests support a payload body as per one of the later specs, whereas an earlier version wasn't fully clear on this and people assumed it's forbidden. Unfortunately, there's still a lot of software conforming to the interpretation of the old spec, which means you cannot count on these HTTP verbs to be supported.

Given this legacy, QUERY seems like an adequate solution. However, it seems to me like it's only intended for read queries. Write queries are generally not cacheable semantically, at least not in my world. Was the naming influenced by GraphQL by any chance, which distinguishes between queries (read) and mutations (write)?

The "idempotency" is that the request should not cause a state transfer from the client to the server that causes the server to change the resource.

That doesn't mean that the server can't change the resource itself for other unrelated reasons.

The practical effect that my coworkers keep telling me about is that the client or an intermediary like a load balancer may retry the same request until it is successful, with the expectation that the resource (records or settings in a database system in our case) is only modified once. A database query that does something like value = OLD.value + 1 cannot be safely retried. There are circumstances under which the outcome of a transaction can be unknown but it might still succeed, and the client should be prevented from doing accidental changes. With read queries this should be rare, but even then there can be side-effects affecting the overall system state. There are of course solutions to this for the application side, like the usage of idempotency keys.

GraphQL is obsolete today as it was when it was released. You have HATEOAS and with it you can take advantage of HTTP caching. No, Redis is not the same.

HTTP methods don't really have functionality inherently attached. They're only semantically meaningful. Occasionally intermediate infrastructure will treat them slightly differently, such as a firewall stripping bodies from GET requests, but that's not part of the spec.

You can even use custom methods. I have a server that responds to the SALAMI method.

Reply on news.ycombinator.com