Does the GraphQL specification define how a request travels over HTTP?

## Two documents, two jobs It helps to see GraphQL as layered. The GraphQL specification defines a language (the syntax of documents and schema definitions), a type system, a validation phase, an execution algorithm, and the shape of a result. That is the whole of it. It says nothing about URLs, methods, headers, status codes or connections, and this is deliberate: the specification talks about *executing a request against a schema*, not about receiving one. Even serialization is left open. The specification discusses how its concepts — maps, lists, null, strings, numbers — should map onto a serialization format and recommends JSON, but does not mandate it. A perfectly conformant implementation could serialize results in a binary format, and some do internally. The serving layer is the second document. The GraphQL over HTTP specification, a working draft rather than a released edition, describes how to express a request as an HTTP request and a result as an HTTP response: the request parameters, the query-string form, the restriction of GET to query operations, the media types and status codes. ## Why this order of events matters GraphQL was released with a reference implementation whose HTTP handling everyone copied. Convergence was social rather than normative: clients were written against the behaviour the first widely used servers happened to have, new servers matched them so those clients would work, and within a couple of years "POST a JSON body with a `query` key to `/graphql`" was universal without being specified anywhere. That history explains the residue. The parts everyone copied early are extremely consistent across implementations. The parts nobody had to agree on — whether GET is supported at all, which status code accompanies a document that failed validation, how strictly the request content type is checked — are where servers still differ, and they are precisely what the working draft is pinning down. ## Why transport-agnosticism is not a technicality It is what allows the same schema and the same execution engine to serve operations that never touch HTTP: - Executing a document in-process against a schema, with no network at all — used for server-side rendering, for tests, and for embedding a graph inside an application. - Subscriptions, which need a long-lived stream and are carried by a WebSocket subprotocol or by a server-sent event stream rather than by a request-response exchange. - Message-based transports inside a system, where an operation arrives on a queue. In every case the execution algorithm is identical; only the envelope changes. If HTTP had been baked into the core specification, each of those would have needed its own dialect. ## What it means to say a document is a working draft A working draft is an in-progress standard: it can gain requirements, tighten wording and reclassify a SHOULD as a MUST between readings. Three habits follow. Quote it as a draft, not as settled law. Do not assume a server you did not write implements the parts you rely on, especially around GET support and status codes. And when you depend on behaviour that appears in neither document, recognise it as a convention your servers happen to share, and write it into your own contract explicitly rather than assuming it travels. ## The interview version of this answer The question is usually phrased casually — "is GraphQL an alternative to REST over HTTP?" — and the difference between a fluent answer and a memorised one is exactly this layering. GraphQL is a query language and an execution model; HTTP is one carriage for it, the dominant one, described by a companion draft. Being able to say which document owns which rule is also the habit that keeps you from attributing a widespread convention to the specification, which is the single most common way GraphQL claims turn out to be wrong. A candidate who adds one concrete example — a subscription that leaves HTTP behind for a stream, or a document executed in-process in a test with no server involved — has demonstrated the point rather than recited it.