REST vs gRPC vs GraphQL

A paradigm is a bet about your consumer

An API paradigm is a bet about who the consumer is and what the traffic looks like. Pick it after you know those two things, not before.

REST

REST is resource-oriented over HTTP. You model nouns (/orders/123), lean on HTTP methods and status codes, and get the entire HTTP ecosystem for free: caching via Cache-Control and ETag, proxies, CDNs, browser tooling, and near-universal client support. That ubiquity is why REST is the default for public developer APIs. The cost is chattiness. A mobile screen that needs a user, their last five orders, and a loyalty balance may make three round trips, and REST tends to over-fetch (you get the whole resource) or under-fetch (you need another call).

gRPC

gRPC is contract-first RPC. You define services and messages in a Protobuf .proto file, generate typed clients and servers in every language, and send compact binary frames over HTTP/2 with multiplexing and bidirectional streaming. On an internal service mesh at high QPS this is the winner: a Protobuf payload is often 3 to 10 times smaller than the equivalent JSON, parsing is faster, and the generated stubs make cross-service calls feel like local function calls. The cost is that it is unfriendly to browsers (you need grpc-web plus a proxy) and to casual curl debugging, and HTTP caches cannot see inside a binary POST.

GraphQL

GraphQL exposes a single typed schema and lets the client ask for exactly the fields it wants in one request. That directly solves the over/under-fetching problem for clients with varied, evolving data needs, which is why product teams with many screens and one flexible backend reach for it. The costs are real: HTTP caching mostly stops working because everything is a POST to /graphql, you must add explicit query-cost limiting and depth limiting to stop a client from asking for the whole graph, and the resolver layer invites N+1 database calls unless you add DataLoader-style batching.

The real answer is usually hybrid

Put REST or GraphQL at the edge where public or client-facing consumers live, and use gRPC between your own services where you control both ends and care about latency and bytes. Netflix, Uber, and Google all run this split.

Two more tools round out the picture. WebSocket and SSE handle server push (chat, live updates) where request/response does not fit. Message queues (Kafka, SQS) handle asynchronous decoupling, where the caller should not wait at all.

Interview nuance: interviewers probe whether you can name what each paradigm costs, not just what it optimizes. "GraphQL is flexible" is a junior answer; "GraphQL trades HTTP caching and needs query-cost limits" is a senior one.

Recap: match paradigm to consumer and traffic (REST public, gRPC internal, GraphQL flexible clients), and expect the real answer to be a hybrid.