REST vs GraphQL
Choosing between REST and GraphQL is a common API design decision and interview question.
Quick answer: REST vs GraphQL
REST vs GraphQL is covered here as a practical system design concept. Choosing between REST and GraphQL is a common API design decision and interview question. Use it to understand the APIs idea, where it appears in production systems, and how to discuss it clearly in interviews.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
What REST vs GraphQL Actually Means
REST (Representational State Transfer) organizes APIs around resources with standard HTTP methods. GraphQL is a query language that lets clients specify exactly what data they need in a single request. REST is simpler and more cacheable; GraphQL is more flexible and reduces over-fetching.
When to Use It (and When Not To)
Choosing between REST and GraphQL is a common API design decision and interview question. The right choice depends on your data access patterns, client diversity, and team expertise.
The Architecture
In REST, each resource has its own URL and supports standard CRUD operations via HTTP methods. The server decides what data to return.
In GraphQL, the client sends a query describing the exact shape of data it needs. The server resolves the query by fetching from databases/services and returns a JSON response matching the query shape. This is powerful for mobile apps (minimize data transfer) and aggregation APIs (combine multiple backend services).
Key Principles
- REST: Resource-based URLs (GET /users/123), standard HTTP methods, stateless, easily cacheable with HTTP cache headers.
- GraphQL: Single endpoint (POST /graphql), client specifies fields in query, no over-fetching or under-fetching, strongly typed schema.
- Over-fetching: REST returns all fields for a resource even if the client only needs 2 fields. GraphQL returns exactly what is requested.
- Under-fetching: Getting a user's posts in REST requires two requests (GET /users/123 then GET /users/123/posts). GraphQL does it in one.
- Caching: REST is naturally cacheable (each URL is a cache key). GraphQL requires custom caching (Apollo cache, Relay store).
Who Does This Well
GitHub migrated from REST to GraphQL because their REST API caused clients to make dozens of requests to render a single page.
Shopify uses GraphQL as their primary public API, letting merchants query exactly the product data they need.
Netflix uses a mix — GraphQL for their client-facing API (flexible queries) and gRPC for internal service communication.
The Hard Parts Nobody Talks About
- Using GraphQL when REST is sufficient — adds unnecessary complexity
- Not implementing query depth limiting in GraphQL — enables abuse
- Returning entire database rows in REST when clients only need a few fields
The Tradeoffs
- Simplicity vs Flexibility: REST is simpler to implement and understand; GraphQL is more flexible.
- Caching: REST leverages HTTP caching natively; GraphQL requires application-level caching.
- Monitoring: REST has clear per-endpoint metrics; GraphQL has one endpoint, making monitoring harder.
- Security: GraphQL allows arbitrary queries, which can be abused (deeply nested queries, excessive data)
Interview Angles
- When would you choose REST over GraphQL?
- What are the problems with REST that GraphQL solves?
- How does GraphQL handle caching?
- What is the N+1 problem in GraphQL?
Keep Learning
Original DosiBridge notes for REST vs GraphQL
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study REST vs GraphQL is to connect the concept to an integration boundary where bad contracts become customer-facing outages. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- Contract Evolution: For REST vs GraphQL, decide the contract evolution before choosing tools; otherwise the design looks clean but fails when rest changes.
- Idempotency: For REST vs GraphQL, decide the idempotency before choosing tools; otherwise the design looks clean but fails when vs changes.
- Pagination: For REST vs GraphQL, decide the pagination before choosing tools; otherwise the design looks clean but fails when graphql changes.
- Error Shape: For REST vs GraphQL, decide the error shape before choosing tools; otherwise the design looks clean but fails when rest changes.
- Consumer Compatibility: For REST vs GraphQL, decide the consumer compatibility before choosing tools; otherwise the design looks clean but fails when vs changes.
Production review question
If a team adopts REST vs GraphQL, what observable signal proves it helped instead of only making the architecture diagram more fashionable?
Practical metric to track
Track rest-graphql health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For REST vs GraphQL, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.