5 posts tagged with "HTTP"

Every GraphQL client eventually has to pick between two HTTP methods, and both come with a problem attached. GET is safe and cacheable, but it puts the whole document into the URL. POST carries the document in a body, but HTTP has to assume that every POST might change something, so caches and retry logic stay away from it. In June 2026 the IETF published RFC 10008, which defines a third option: QUERY, a method that carries a body like POST and is safe and idempotent like GET. That description also fits a GraphQL query operation very closely.

Send a GraphQL server a document with a typo in it, and for most of the last decade the answer came back as 200 OK. Ask for a field that does not exist, and you got 200 OK. Run a query that half worked, and you got 200 OK again, with the bad news inside the body. Load balancers, CDNs and dashboards do not read response bodies, so to them all three requests looked like successes. The GraphQL over HTTP specification is getting its first edition, named September 2026, and its main job is to let the status code tell the truth again without breaking the clients that learned to ignore it.

Every GraphQL tutorial on subscriptions starts the same way: "First, upgrade your HTTP connection to a WebSocket." Then comes the lecture on graphql-ws, the Sec-WebSocket-Protocol header, ping/pong frames, and the eight ways your connection can die without explanation. You nod through it, ship your subscription, and a month later a customer calls because their corporate firewall blocks wss:// and nothing works. Welcome to 2026, where GraphQL over Server-Sent Events has quietly become the pragmatic alternative that just works.

For a decade, GraphQL responses came back as one lump. You asked for a page, you waited for every field to resolve, then the server wrapped it up and sent it over the wire in one envelope. Fast fields waited for slow fields. The whole response moved at the speed of its slowest resolver. Then @defer and @stream arrived to fix exactly that. They've been maturing as a proposal for several years - deliberately, because getting incremental delivery right is genuinely hard - and they're now real enough to use with modern clients and servers. The open question is when they pay off, and both camps have a case.

Every GraphQL query you send travels over HTTP. Every response comes back the same way. But here's the thing: HTTP was designed for fetching documents, not executing queries. GraphQL essentially hijacked a delivery truck and turned it into a taxi service. Let's explore the protocol that makes it all possible.