How is a GraphQL operation encoded in a GET request, and which operations may travel that way?

## The same parameters, a flatter container The GraphQL over HTTP working draft describes one request with two carriers. A POST puts `query`, `variables`, `operationName` and `extensions` into a JSON body. A GET puts the same four into the URL's query string. Nothing about execution changes: the server ends up with the same document, the same variable map and the same operation selection either way. What does change is the encoding, and the reason is that a query string has no types. It is a flat sequence of `name=value` pairs of text. `query` and `operationName` are already strings, so they are simply percent-encoded — braces, spaces, `$`, `:` and parentheses all become escapes, which is why a hand-written GraphQL URL looks like line noise. `variables` and `extensions` are maps, and a map cannot be expressed in that grammar. So the rule is two-step: serialize the map to JSON, then percent-encode the resulting JSON text as the parameter value. The server reverses it — percent-decode, then JSON-parse — and coerces each variable against the operation's declared type exactly as it would from a POST body. This is the single most common GET mistake in practice. A client that passes the variables object straight through, or spreads it into repeated `variables[restaurantId]=r-4417` pairs, produces a request the server cannot read, and the failure looks like a variable-coercion error rather than an encoding error. ## Why GET is limited to query operations A GET is a read. Nothing in an HTTP GET's contract permits it to change state, and every layer between a client and a server is built on that assumption: a link can be followed, a request can be repeated, a tool can prefetch. GraphQL puts the operation type inside the request body or the `query` parameter, where none of those layers can see it, so the serving rules close the gap by restricting the method: GET carries `query` operations. A server that parses a GET and finds a mutation must not execute it and answers with a refusal instead of a result. That restriction is worth stating in an interview as a *serving* rule rather than a language rule. Nothing in the GraphQL language forbids a mutation document from being sent any particular way; it is the HTTP layer that draws the line, because the meaning of the method belongs to HTTP. ## What GET buys and what it costs The attraction of GET is that a read stops being opaque. The method itself now says "this is a read", which matters to everything that inspects traffic without parsing bodies. The costs are real and worth naming precisely. **Length.** The document, the variables and the operation name all have to fit in a URL. Browsers, reverse proxies and server request-line limits impose ceilings — commonly a few kilobytes — and they are enforced before your code sees the request, so an overlong document fails at the edge with an HTTP-level error and no GraphQL response shape at all. In a restaurant ordering graph, `MenuBoard` with one variable fits comfortably; a deeply nested order-history document with fragments will not. **Exposure.** URLs are logged by every hop, kept in browser history, and can leak through referrers. A POST body is not treated that way by default. If a variable carries anything sensitive — a customer identifier, a token — moving it into a URL moves it into everyone's logs. **Uniformity.** Client code that must decide per operation whether to use GET or POST is more code and one more thing to get wrong, which is why many teams simply POST everything and accept the opacity. ## The shape of a real request For a query named `MenuBoard` taking `$restaurantId: ID!`, the GET is a single URL with three parameters: the escaped document, `operationName=MenuBoard`, and `variables` holding the percent-encoded text `{"restaurantId":"r-4417"}`. The document is unchanged from what would have been POSTed — same text, same fragments, same variable definitions. ## Interview traps Candidates often say "GraphQL only works over POST". It is a reasonable description of what most clients do by default, but it is not true of the serving rules, and the follow-up — *how would you send a query over GET* — is exactly what the interviewer is waiting for. The second trap is claiming that a mutation over GET is fine if the server is willing; the whole point of the restriction is that willingness is not the issue, the method's meaning to intermediaries is.