Feature Request: consider supporting HTTP QUERY method

[StevenACoffman]

Feature Request: knit provides client-centric queries like GraphQL but better enables HTTP caching by supporting the HTTP QUERY method.

Using HTTP POST to make queries it is not readily apparent -- absent specific knowledge of the resource and server to which the request is being sent -- that a safe, idempotent query is being performed. As a result the same exact idempotent HTTP POST query is often not cached by LoadBalancers and other HTTP Proxies.

GraphQL provided batching to improve performance by combining multiple queries so it can be made over a single HTTP 1.1 connection. However, HTTP/2 (and HTTP/3) multiplexing make most batching techniques counterproductive to performance.

Another example of a GraphQL gateway batching is an Apollo GraphQL Federation query. In an Apollo Federation Query a single Federated Query is handled by a gateway that decomposes that query that into multiple subgraph queries and combines the results into a single response. This makes the slowest subgraph query delay the response of the overall Federated GraphQL Query of the composed SuperGraph. Apollo Federation further increases the difficulty of independent deployability and testability. Apollo Federation also makes it hard to provide the client with meaningful partial success and partial errors when subgraph queries return errors.

Independent of performance, GraphQL under HTTP/2 still provides the benefit of client-centric queries. Instead of a server backend needing to foresee and provide the right level of granularity in it's endpoints, a client is able to precisely describe what information is required. GraphQL provides a client-centric unified discovery mechanism for newly available data components.

knit provides a similar client-centric benefit, so that neither overfetching nor underfetching is a problem. I think it can do so while improving performance in HTTP/2 multiplex environments if it used the upcoming HTTP QUERY method.

Every 6 months, the IETF expires a draft and publishes a new version of the draft so this is the current version:

• https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-06.html

As to how active the proposal is, you can see a lot of revisions in the GitHub history of the source document here: https://github.com/httpwg/http-extensions/commits/main/draft-ietf-httpbis-safe-method-w-body.xml

And use the IETF data tracker to track the activity on mailing lists and whatnot:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/

There have been very few impactful changes since the rename of the method to QUERY. The IETF HTTP Working Group is continuing to flesh out the documentation for this extension and its implications for how it interacts with various other standards and edge cases before getting approval for publication by the Internet Engineering Steering Group (IESG). It's relatively uncontroversial, they are just polishing now.

FWIW Node 22.2.0 supports HTTP Method Query