System Design › Fundamentals

API Design: REST vs gRPC vs GraphQL (How to Choose)

REST, gRPC, and GraphQL explained from scratch — and exactly when to pick which. A fresher-to-senior guide with a comparison diagram, plus API versioning and pagination.

Shiv Pandey

Sep 30, 2026 | 67 views

API Design: REST vs gRPC vs GraphQL (How to Choose)

🔵 Fundamentals · Fresher-friendly → 🟠 senior nuance

An API is the contract that lets one piece of software talk to another — your app to its server, or one microservice to the next. How you design that contract shapes everything: speed, flexibility, how easy it is to evolve. Three styles dominate: REST, gRPC, and GraphQL. This guide explains each from scratch and, crucially, when to pick which — a question that comes up in almost every design interview.

The one idea to hold onto: an API is a menu of allowed requests plus the exact format for making them. REST, gRPC, and GraphQL are three different styles of writing that menu — each optimised for a different priority (simplicity, speed, or flexibility).

REST — the web's default

REST models everything as resources (users, orders, posts) that you act on with standard HTTP verbs. It's simple, universal, and works in every browser and tool.

GET    /users/42          → read user 42
POST   /users             → create a user
PUT    /users/42          → replace user 42
DELETE /users/42          → delete user 42

Key REST principles worth naming: it's stateless (each request carries everything the server needs — no memory of past requests, which is what makes servers easy to scale), and verbs have semantics — GET is safe (no changes), and PUT/DELETE are idempotent (doing them twice equals once). Responses are usually JSON. REST is the right default for public APIs and most web apps: everyone understands it, and it's easy to cache and debug.

The weakness: over- and under-fetching. A GET /users/42 returns the whole user even if you only wanted their name (over-fetching), and building a screen may need several round-trips — user, then their posts, then each post's comments (under-fetching). That's exactly what GraphQL fixes.

GraphQL — ask for exactly what you need

🟠 GraphQL exposes a single endpoint where the client specifies precisely which fields it wants, in one request. No more over- or under-fetching.

query {
  user(id: 42) {
    name
    posts(last: 3) { title }   ← user + last 3 post titles,
  }                            ← in ONE request, nothing extra
}

Great for: apps with many different screens/devices needing different data shapes (mobile wants less than desktop), and for reducing round-trips on slow networks. The cost: caching is harder (it's not simple URL-based GET caching), the server is more complex, and a careless query can ask for something huge and expensive. Powerful, but not free.

gRPC — fast service-to-service

🟠 gRPC is built for speed between servers. Instead of JSON text over HTTP/1.1, it sends compact binary (Protocol Buffers) over HTTP/2, with a strict, shared schema and generated client code. It's significantly faster and lighter than REST, and supports streaming.

Great for: internal microservice-to-microservice calls where performance matters and both sides are yours. The catch: it's not natively browser-friendly (needs a proxy), and binary payloads are harder to eyeball/debug than JSON. So gRPC shines behind the scenes, not usually as your public API.

Side by side

The senior answer: how to choose

🟠 There's no "best" — there's fit. A crisp interview answer:

Public API or a standard web/mobile app? → REST. Simple, cacheable, everyone gets it.
Rich client pulling varied data across many screens, over mobile networks? → GraphQL. Fetch exactly what each screen needs in one call.
High-throughput internal service-to-service calls? → gRPC. Binary speed, strict contracts.

And these mix: a company often exposes REST or GraphQL to the outside world and uses gRPC between its internal services. Naming that combination shows you think in trade-offs, not fandom.

Two things every API needs, whatever the style

🟠 Regardless of REST/gRPC/GraphQL, senior reviewers look for two more things:

Versioning: APIs change, and you can't break existing clients. Plan for it (e.g. /v1/, /v2/, or schema evolution) from day one.
Pagination: never return "all users" — return a page at a time (cursor- or offset-based), or a big list will crush both server and client.

Mentioning versioning and pagination unprompted signals you've built real APIs, not just toy ones.