REST vs GraphQL vs gRPC — when would you choose each?

Question

IT Interview Practice · Accepted Answer

These are three different API paradigms, each optimized for different constraints. There is no universal winner — the right choice depends on the **consumer, the data shape, and the network**.

## The three at a glance

```text
           REST                 GraphQL              gRPC
Style      resources + HTTP     single query graph   RPC (call methods)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binary)
Fetching   fixed endpoints      client picks fields  fixed methods
Schema     optional (OpenAPI)   strong, typed        strong, .proto
Browser    native, cacheable    needs client lib     limited (needs proxy)
```

## REST

Resource-oriented over plain HTTP. **Choose it** for public APIs, CRUD services, and anything that benefits from HTTP caching, ubiquity, and simplicity. Its weaknesses are **over-fetching** (you get the whole `/users/42` even if you need one field) and **under-fetching** (the `N+1` problem: fetch a user, then loop to fetch each order).

```http
GET /users/42            → the whole user
GET /users/42/orders     → a second round trip
```

## GraphQL

A single endpoint where the **client specifies exactly what it wants** in one query, solving over/under-fetching. **Choose it** for rich frontends (especially mobile, where round trips are costly) and when many clients need different shapes of the same data.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
Trade-offs: HTTP caching is harder (everything is a `POST` to `/graphql`), and a naive resolver can hide expensive `N+1` database queries.

## gRPC

Contract-first RPC using **Protobuf** over **HTTP/2**. Binary and multiplexed, so it's fast and compact with streaming support. **Choose it** for **internal service-to-service** communication in a microservices backend where performance and strict typing matter. Weakness: poor browser support (needs a proxy like grpc-web) and not human-readable.

## Choosing

```text
Public API, CRUD, caching, wide reach   → REST
Complex/varied frontend data needs      → GraphQL
High-performance internal microservices → gRPC
(Real systems mix them: REST/GraphQL at the edge, gRPC between services.)
```

## Why it matters

At senior level, interviewers care less about definitions and more about whether you can **justify a choice against constraints** — this question is really "can you match a technology to a problem instead of chasing hype?" The strongest answers anchor on the pain each one solves: GraphQL exists to kill over/under-fetching for demanding frontends, gRPC exists to make internal service calls fast and strongly typed, and REST remains the default because HTTP caching, tooling, and universal familiarity are enormous practical advantages for public and CRUD-style APIs. Crucially, a senior engineer notes it's **not either/or** — a common architecture is REST or GraphQL at the public edge with gRPC between backend microservices — and names the concrete trade-offs (GraphQL's caching and `N+1` risks, gRPC's weak browser story). That reasoning about fit and cost, not the ability to recite features, is the signal.

The three at a glance

REST

GraphQL

gRPC

Choosing

Why it matters

Related questions