What each one actually is

REST (Representational State Transfer) is an architectural style for using HTTP as it was designed: resources identified by URLs, manipulated with standard methods, with state transferred as representations. There is no canonical REST spec — the term comes from Roy Fielding's PhD dissertation.

GraphQL is a query language and runtime for APIs, originally developed at Facebook and released as an open spec. Clients send queries to a single endpoint; the server resolves them against a typed schema and returns exactly the requested fields.

Side-by-side

RESTGraphQL
EndpointsMany — one per resourceUsually one
HTTP methodsFull vocabulary (GET, POST, PUT, PATCH, DELETE)Almost always POST
Response shapeDefined by serverDefined by client query
Over-fetchingCommon (return entire resource)Rare (query exact fields)
Under-fetchingCommon (multiple round trips)Rare (one query covers nested data)
HTTP cachingNative (URL + ETag)Awkward — single POST URL
VersioningPath / header / media typeSchema evolution (deprecate fields)
ToolingOpenAPI / SwaggerNative introspection
Status codesPer-responseAlways 200; errors in payload
Real-timeWebSockets / SSE separatelySubscriptions in the spec

When REST shines

When GraphQL shines

i

It's not either-or. Many production systems run both — REST for cache-friendly endpoints and file delivery, GraphQL for product surfaces. There is also Connect and gRPC for service-to-service traffic where strict typing and performance matter more than human ergonomics.