Printing and PDF export are disabled for this content. View it online at Full Stack Learning Simplified.

GraphQL vs REST

GraphQL directly addresses two common REST pain points: over-fetching (getting more than you need) and under-fetching (needing several requests to assemble one view).

The two problems

Over-fetching — a REST endpoint returns a fixed, often-large payload even when you need two fields.
Under-fetching — building one screen needs /user, then /user/1/posts, then /posts/5/comments (the “waterfall”).

GraphQL fixes both: one query fetches exactly the fields you want across related resources.

Side by side

	REST	GraphQL
Endpoints	many (one per resource)	one
Response shape	fixed per endpoint	client decides
Multiple resources	several requests	one query
Versioning	often /v1, /v2	evolve the schema, deprecate fields
HTTP caching	built-in (GET + URLs)	needs extra work

One request vs a waterfall

compare

# REST: 3 round-trips
GET /users/1
GET /users/1/posts
GET /posts/5/comments

# GraphQL: 1 query
query { user(id:1){ name posts{ title comments{ text } } } }

Where REST still wins

Simple CRUD APIs — REST is less machinery.
HTTP caching / CDNs — REST GETs cache naturally.
File uploads/downloads and standard status codes.

Note: GraphQL isn't universally “better” — it trades REST's simplicity and free HTTP caching for flexibility. Many teams use both: GraphQL for rich client APIs, REST for simple service-to-service endpoints.

Tip: Choose GraphQL when many clients need different, related slices of data (especially mobile). Choose REST when the API is simple, cache-heavy, or you want to lean on HTTP's built-in semantics.

Free preview. Sign in and subscribe to unlock all 809 lessons across 25 courses.