# REST vs GraphQL > Choose REST for resource-oriented APIs where predictable operations and straightforward HTTP caching matter most. Choose GraphQL when clients need different combinations of related data and a typed, client-selected response is worth the added query-cost and resolver complexity. Neither choice determines your database, consistency model, or transaction guarantees. Source: https://sysround.com/compare/rest-vs-graphql Updated: 2026-11-05 ## Side by side | | REST | GraphQL | |---|---|---| | API model | Resources addressed by URLs; HTTP methods express operations | Typed schema; clients select fields through queries and mutations | | Response shape | Server-defined; optional projections or specialized endpoints | Client-selected fields within the schema | | Related data | Multiple requests or server-built aggregate endpoints | One operation can traverse related types | | Caching | GET responses fit standard HTTP and CDN caching | Shared caching needs deliberate operation and cache-key design | | Backend work | Usually easier to bound per endpoint | Depends on selected fields, list sizes, and resolver fan-out | | Traffic protection | Per-route quotas plus operation-specific limits | Cost budgets, pagination caps, and execution limits | | Contract evolution | Additive changes, deprecation, and versions when needed | Additive schema changes and field deprecation | | Errors | HTTP status codes plus structured response bodies | Execution can return partial data with field-level errors | ## The differences that matter REST is an architectural style; GraphQL is a query language and execution model. In an interview, the practical comparison is usually a resource-oriented HTTP API versus a GraphQL API. Both can use the same services and databases, and a GraphQL layer can call existing REST services. GraphQL lets a mobile client request a compact profile while a desktop client requests the profile, recent posts, and follower counts. This can reduce client round trips and unused response fields, but it does not automatically reduce backend work. REST can also provide field selection, embedded resources, or a screen-specific aggregate endpoint. REST GET responses naturally fit HTTP cache keys, validators, and CDN policies when the data is safe to share. GraphQL responses can also be cached, but arbitrary query documents and variables complicate shared response caching. Persisted queries served through GET can make this more manageable; personalized data still requires correct identity scoping and invalidation. GraphQL moves more execution planning into the API layer. A list of posts with author fields can trigger one author lookup per post unless resolvers batch or reuse reads. Bound list sizes and query cost, enforce authorization on every relevant access path, and trace resolver fan-out. REST endpoints need the same backend protections, but their allowed work is often easier to estimate from the route. ## Choose REST when - You expose stable resource operations such as creating uploads, reading listings, or canceling reservations, with limited variation between clients. - Public, read-heavy responses should be cached at a CDN using familiar HTTP semantics. - You need predictable per-operation costs, clear route-level metrics, and a small API operations surface. - A few aggregate endpoints can meet client needs without introducing a general graph execution layer. ## Choose GraphQL when - Web, mobile, and partner clients need substantially different selections of the same related data. - Screens otherwise require several client requests, and those requests can be composed behind one schema with bounded backend fan-out. - You can invest in schema ownership, resolver tracing, batching, pagination limits, and query-cost controls. - Clients benefit from schema validation and generated types, and the team can manage field deprecation as clients migrate. ## Worked example: A photo feed with different mobile and desktop needs Suppose a feed page shows 20 posts. Mobile needs captions, thumbnail URLs, and author names; desktop also needs comment previews. A REST design could return this through one feed endpoint with a bounded include parameter, while GraphQL could expose the selections explicitly. With naive resolvers, the GraphQL request might perform one feed read plus 20 author lookups and 20 comment lookups: 41 backend calls despite one client request. Batch author and comment reads, cap previews at three comments per post, and measure the remaining fan-out. Choose GraphQL if client variation justifies the schema machinery; otherwise, the aggregate REST endpoint may be simpler. ## In the interview - Start with a concrete screen or operation. List its data dependencies, response size constraints, and latency target before choosing the API style. - Distinguish client round trips from backend calls. If GraphQL combines several reads, explain which can run in parallel and how you prevent N+1 lookups. - Describe the cache boundary: public response caching, user-scoped responses, service caches, or entity caches. Expect questions about permission changes and stale data. - Explain abuse controls. For GraphQL, discuss bounded pagination, estimated query cost, execution deadlines, and trusted persisted operations where appropriate; for REST, discuss expensive endpoints and batch limits. - Keep correctness separate from API syntax. Expect follow-ups on mutation idempotency, transaction boundaries, authorization, and how clients handle partial failures. ## Common mistakes - Claiming GraphQL is faster because it uses one request, without counting resolver calls, database queries, or response size. - Saying REST cannot aggregate data or GraphQL cannot be cached. Both are possible, with different implementation and operational costs. - Applying only a requests-per-minute limit to GraphQL while allowing deeply nested queries or unbounded lists. - Assuming a GraphQL mutation is an atomic transaction, or that schema validation replaces object-level authorization. ## Interview questions where it comes up - [Design a news feed like Facebook](https://sysround.com/questions/design-news-feed): Feed response composition exposes the trade-off between client-selected fields and predictable, bounded retrieval of posts and related metadata. - [Design Instagram](https://sysround.com/questions/design-instagram): Mobile and web clients can need different post metadata, while media delivery remains separate from the API response. - [Design Facebook Marketplace](https://sysround.com/questions/design-facebook-marketplace): Discovery and listing-detail screens require different data shapes, with pagination and current listing state constraining either API design. - [Design Google Photos](https://sysround.com/questions/design-google-photos): A strong answer separates flexible metadata queries from resumable object transfers and enforces album permissions across all query paths. ## FAQ ### Is GraphQL faster than REST? Not inherently. GraphQL can reduce client round trips and unused fields, but resolver fan-out can increase backend work. Compare end-to-end latency, transferred bytes, cache hit rates, and backend calls for the actual access pattern. ### Can GraphQL replace REST? GraphQL can replace some client-facing REST endpoints, or sit in front of existing REST services. It does not replace every delivery mechanism: media downloads, webhooks, and bulk transfers often remain separate HTTP interfaces. A system can use both without duplicating its core business logic. ### Is REST more secure than GraphQL? Neither is inherently more secure. Both require authentication, object-level authorization, input validation, and resource limits. GraphQL additionally needs careful controls on query complexity and consistent authorization across paths to the same object. ## Related concepts - [REST API design](https://sysround.com/concepts/rest-api-design) - [GraphQL](https://sysround.com/concepts/graphql) - [Caching strategies](https://sysround.com/concepts/caching-strategies) - [API versioning](https://sysround.com/concepts/api-versioning) - [Pagination](https://sysround.com/concepts/pagination) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.