GraphQL Errors
GraphQL errors describe query or resolver failures in an errors array alongside optional data when partial results are allowed. Each error includes message, path, locations, and extensions for codes, which differs from REST where non-2xx HTTP status often means no body convention at all.
Technical Architecture & Deep-Dive
A resolver may fail for one field while siblings still return values, producing HTTP 200 with errors populated. Clients must check both data and errors, not status codes alone.
Edge GraphQL gateways can map provider errors to stable extension codes, strip internal stack traces, and align fatal failures with Problem Details on non-GraphQL routes. Slimming error extensions reduces payload size on mobile and prevents leaking implementation details.
Key Architectural Benefits
Implement GraphQL Errors at the Edge
Deploy lightweight API aggregation, edge caching, and secret injection in minutes without Docker containers or complex servers.
Frequently Asked Questions
Q:Why do GraphQL errors sometimes return HTTP 200?
The spec treats HTTP as transport. Application-level failures may still use 200 with errors while validation issues may use 400.
Related Architecture Concepts
Problem Details (RFC 7807) standardize HTTP error bodies as application/problem+json objects with type, title, status, detail, and optional instance fields. Clients parse one predictable shape across services instead of guessing whether errors live in message, error, or errors arrays.
GraphQL is a query language and runtime for APIs in which clients send a query describing exactly the fields they need, and the server returns JSON matching that shape. A strongly typed schema defines available data, and a single endpoint replaces many REST routes.
An API response envelope is a wrapper object around the actual data, typically containing fields like data, meta, errors, and pagination. Envelopes give every response a consistent outer structure, making it easier to handle errors and paging uniformly.