GraphQL

GraphQL replaces many resource URLs with one endpoint and a typed schema. The client sends a query describing the shape of the data it needs — this user, their last three orders, each order's total — and receives exactly that shape back. Writes are mutations, sent the same way.

How it works

The server validates each query against its schema before running it, then resolves each field, possibly from different data sources. Requests are usually POSTs with the query in a JSON body. Errors are reported in an errors array alongside whatever data could be resolved, typically with a 200 status for the HTTP request as a whole.

The misconception

That GraphQL replaces HTTP status codes. Because a partially failed query still returns 200, a client that checks only the status will miss field-level errors entirely; the errors array has to be inspected on every response. The same flexibility also means a single query can be very expensive, which is why production servers limit depth and complexity.

Try it here

POST https://funapi.dev/graphql runs queries and mutations over the Friends characters, with a GraphiQL explorer at the same URL; the Friends API docs page also runs it as POST /graphql in the Try it out panel.

Sources

GraphQL specification

Other terms

REST API — An API that models a system as addressable resources, manipulated with standard HTTP methods.
API endpoint — One URL plus one HTTP method — the smallest unit of an API that a client can call.
Query parameters — The key=value pairs after the ? in a URL, used to filter, sort, page or shape what an endpoint returns.
Path parameters — A variable segment of a URL path, such as the 42 in /orders/42, that identifies one specific resource.
HTTP headers — Name–value metadata sent with every request and response, separate from the body.
HTTP status codes — The three-digit number at the start of every HTTP response that says, before the body, what happened.

All glossary terms · Testing techniques · All 39 mock REST APIs

Last updated 16 October 2026