REST vs GraphQL
Compare REST and GraphQL by client needs, data ownership, caching, evolution, performance, and operational complexity.
What you'll learn
Make the call with confidence
- When stable resource endpoints keep an API simpler than a query graph.
- How GraphQL shifts composition, authorization, and performance responsibility to the API layer.
- How to assess caching and evolution rather than treating either style as universally modern.
REST and GraphQL are ways to make an API contract useful to clients. REST organizes stable resource-oriented endpoints. GraphQL gives clients a typed graph they can query precisely. The better choice depends on who owns composition, how varied clients are, how expensive data fetching is, and how much governance the team can sustain.
Start with the tradeoff map, then use the guide to pressure-test the decision against your workload and constraints.
Keep the gain and the cost visible at the same time.
ATOFF architecture reasoning canvas
REST vs GraphQL: the tradeoff map
Short answer
REST suits stable resource boundaries and broad caching; GraphQL suits varied client composition when the team can govern a shared typed graph.
Decision trigger
Adopt GraphQL when client-composition savings justify central query governance.
01 Decision checkpoint
Choose A
Use explicit resource endpoints when clients have predictable needs, HTTP caching is useful, and independent teams need simple operational boundaries.
02 Decision checkpoint
Choose B
Use a composed graph when multiple clients need different projections and a gateway can prevent inefficient resolver fanout.
03 Decision checkpoint
Hidden cost
GraphQL moves batching, authorization, query limits, and schema stewardship into the platform; plan those controls before adopting it.
Say it in the interview
I would choose based on who composes data, how diverse client reads are, and how I will control query cost and authorization.
- 1
How varied are client data shapes?
fits when: REST: stable endpoint contracts · fits when: GraphQL: client-selected graph
- 2
REST: stable endpoint contracts
- 3
GraphQL: client-selected graph
- How varied are client data shapes? flows to REST: stable endpoint contracts via fits when.
- How varied are client data shapes? flows to GraphQL: client-selected graph via fits when.
Evidence for the choice
The core choice is contract shape and ownership
REST works well when resources and actions are clear, client needs are mostly predictable, and HTTP semantics, caching, and observability should remain straightforward. A well-designed REST API can offer focused endpoints without making clients over-fetch meaningfully.
GraphQL is compelling when multiple clients need different combinations of related data and a shared typed graph can prevent a proliferation of bespoke aggregation endpoints. It does not remove backend complexity; it moves composition into resolvers and schema governance.
GraphQL precision can hide expensive resolver behavior
A graph query that looks compact can fan out into many backend calls. Resolver batching, depth limits, complexity budgets, persisted queries, and field-level observability are necessary to prevent an elegant API from becoming an unpredictable load generator.
REST aligns naturally with HTTP caches when resource URLs and cache directives are meaningful. GraphQL can be cached too, but the cache key, invalidation, and partial response model require more deliberate design.
Schema evolution and authorization are ongoing work
Both styles need backward compatibility. REST often adds fields or versions a contract at a clear boundary. GraphQL can deprecate fields, but its flexibility means unused fields may survive indefinitely and a schema can become a sprawling interface without ownership.
Authorization must be enforced on the underlying action or field, not assumed from a top-level route. A graph makes it particularly important to prove that a caller can see each traversed relation.
Interview answer: choose based on client diversity and backend shape
A strong answer describes the client population, data-composition need, backend call graph, and cache strategy. For example, start with REST for a small set of stable workflows, then introduce a GraphQL aggregation layer when independently evolving clients are repeatedly stitching together many resources.
At staff level, discuss platform ownership: schema review, performance budgets, deprecation policy, cost attribution, and guardrails that prevent one client query from consuming shared backend capacity.
Keep this with you
Key takeaways
- REST and GraphQL are contract choices; both require good data ownership and evolution practices.
- GraphQL needs explicit resolver performance, query-cost, and authorization controls.
- Use client diversity and composition needs to decide where aggregation belongs.
Practice aloud
Interview questions to explore
- 1.How would you prevent a nested query from causing unbounded backend work?
- 2.Which client need justifies a graph over focused REST endpoints?
- 3.How will you observe and attribute query cost by client?
Common follow-ups
Frequently asked questions
Is GraphQL faster than REST?
Not inherently. It can reduce unnecessary payloads, but resolver fanout and cache complexity can make it slower without careful batching, query limits, and backend design.
Can REST and GraphQL coexist?
Yes. Many organizations keep stable operational REST endpoints while using GraphQL as a carefully governed aggregation layer for specific client experiences.
Need the broader preparation context? Go back to Interview Preparation for behavioral readiness, question practice, and the larger AceTheOffer preparation framework.