Is an array of operations in one GraphQL request body part of the specification?

## What the specifications actually describe The GraphQL specification defines a *request* as a document, an optional operation name, and a set of variable values, and it says nothing whatever about HTTP. The rules for expressing that request as an HTTP request live in the separate GraphQL over HTTP specification, which is a working draft; it describes a single GraphQL request per HTTP request, carried as a JSON object with `query`, `variables`, `operationName` and `extensions`, or as URL parameters for a GET. Neither document defines an array. So array batching is a **convention**. It arose because early client libraries wanted to collapse the several documents a page fires on load into one round trip, servers added support, and the shape became folklore. It is well established and widely implemented — and it is not a feature you can assume of an arbitrary GraphQL endpoint, nor one whose behaviour is pinned down anywhere you can cite. ## The conventional shape A batched body is a JSON array whose members are ordinary request objects. The response is a JSON array of ordinary results, paired with the requests **by position**. Each member gets its own `data` and its own `errors`; there is one HTTP status code, one set of response headers, and one connection for the whole array. Because none of this is specified, every property you might want to lean on is a per-server decision: - **Order and concurrency.** Nothing says the members run in order, or that they run one at a time. A server may execute them concurrently. - **Isolation.** There is no transaction around the array. Two mutations in one batch are two independent operations that happen to share a socket. - **Partial failure.** A member that fails produces a result object with an `errors` array like any other operation; the HTTP status still describes the *transport*, not the outcomes. But a body that fails to parse, or a member the server refuses, may collapse the whole array into a single request error — which shape you get is implementation-defined. - **Size.** Some servers cap the member count; many disable batching by default; some never supported it. ## Why the convention question is a security question Every control that counts *HTTP requests* divides by the batch factor. A per-IP limit of 30 requests per minute becomes 30 × N operations per minute the moment N-member arrays are accepted. A per-request cost budget applied once to the body lets each member spend the whole budget. A log pipeline that emits one line per request now hides N operations behind it. And an authorization check performed once at the edge covers operations it never inspected. The mirror-image trap is *retries*. A client posts a five-member batch against a translation-memory graph: three reads and two `commitTranslation` mutations writing new target text for segments in an 8,400-row review page. The server executes members three and four, then the request exceeds the client's socket timeout and the client — reasonably, by its own lights — retries the whole array. The two commits run a second time. If `commitTranslation` appends a revision rather than setting one, the retry leaves **a duplicate write** that no HTTP status ever reported, because the first attempt's status never arrived. Nothing about batching creates this hazard by itself; batching enlarges it, by making a single retriable unit out of operations that have different idempotency properties. ## Deciding what to do about it Three defensible positions, in rough order of how often you will see them: 1. **Reject arrays.** If your clients do not need it, an endpoint that accepts only a JSON object is one fewer multiplier to reason about, and rejecting it is a content-shape check that costs nothing. 2. **Accept with a member cap, and apply limits per member.** Parse the array, then run every downstream control — cost scoring, field-occurrence caps, attempt counters, logging — once per member rather than once per body. The cap bounds the parse-time work; the per-member accounting bounds everything after it. 3. **Accept for reads only.** Mutations in a batch are the part that carries the retry and ordering hazards; reads are merely expensive. ## What an interviewer is listening for The crisp answer is: "No, it is not specified — the core spec has no HTTP, and the HTTP spec describes one request per request. Array batching is a convention, an array in and an array of results out matched by position, with no atomicity and no defined ordering." The follow-through that separates a good answer from a recited one is noticing that every per-request control silently becomes a per-N-operations control, and that a retried batch re-runs whatever already succeeded.