REST vs GraphQL

REST vs GraphQL is one of the most asked questions in backend interviews — and one of the most misunderstood. The truthful answer is boring: both work, pick the one that fits your problem. This guide explains what they actually are and when each wins.

If you understand the trade-offs below, you can answer interview questions on the topic and make the right call on a real project.

1. REST in one paragraph

Resources mapped to URLs. HTTP verbs (GET, POST, PUT, DELETE) describe the action. Each endpoint returns a fixed shape. Simple, cacheable, ubiquitous. Default choice for most APIs in 2026.

2. GraphQL in one paragraph

A single endpoint. Clients send a query specifying exactly what fields they want. Server resolves the query and returns just those fields. Solves over-fetching and under-fetching — clients get what they need, no more.

3. Over-fetching, the core problem

With REST, /users/42 returns the whole user object even if you only wanted the email. With GraphQL, you ask for just the email, you get just the email. On mobile/bandwidth-sensitive apps, this matters.

4. Under-fetching, the other core problem

To show a user’s posts and comments, REST often needs 3 requests. GraphQL does it in 1. Fewer round trips = faster. Big win for complex UIs with lots of related data.

5. Where REST wins

Simple CRUD APIs. Public APIs where consumers vary (cacheability matters). Microservices with small surface areas. Teams without GraphQL experience. You don’t pay the complexity cost when you don’t need the flexibility.

6. Where GraphQL wins

Complex frontends pulling from many resources. Mobile apps minimizing bandwidth. Apps with many client types (web + mobile + watch) each needing different data shapes. APIs serving many teams with different needs.

7. Caching is harder in GraphQL

REST piggybacks on HTTP caching — CDNs just work. GraphQL queries are POSTs, so standard HTTP caching doesn’t apply. You need client-side caching (Apollo, Relay) and careful server-side caching. Real operational cost.

8. File uploads and binary data

REST handles these naturally. GraphQL needs extensions (multipart spec). Small friction but real. If your API is file-heavy, REST is simpler.

9. Rate limiting and throttling

Easier with REST — count requests per endpoint. With GraphQL, one query can fetch a lot or a little; you need complexity-based throttling (query cost analysis). Not impossible, just more work.

10. Learning curve

REST is basically free — it’s just HTTP. GraphQL adds schemas, resolvers, clients, tooling. Steeper ramp-up for new team members. Budget training time if you adopt it.

11. The hybrid approach

Many companies use REST for public APIs and GraphQL for internal frontends. Or gRPC between services + REST externally. You don’t have to pick one for the whole system.

12. Interview answer

“REST is the default — simpler, cacheable, universally supported. GraphQL wins when you have complex nested data and multiple client types. I’d start with REST unless the over-fetching pain was real.” See what is an API for the fundamentals, and interview prep for more.