gRPC vs REST: which API style to choose

REST usually means JSON over HTTP with resources and verbs (GET /users/42). gRPC is a remote procedure call framework from Google that uses Protocol Buffers (a compact binary format) over HTTP/2.

How gRPC works

You define services and messages in a .proto file. Tools generate client and server code in many languages. Calling a remote method then feels like calling a local function, with strong types.

Strengths of gRPC

• Small and fast: binary encoding is smaller than JSON, and HTTP/2 multiplexes many calls on one connection.
• Streaming: server, client and bidirectional streams are built in.
• Strict contract and code generation: fewer mismatches between services, and easy versioning rules.
• Deadlines, cancellation and metadata are first-class.

Strengths of REST

• Universal: every language, browser and tool understands it.
• Human-readable: easy to debug with curl or a browser.
• Cacheable: HTTP caching and CDNs work naturally with GET.
• Simple to learn and to expose publicly.

Weaknesses

• gRPC: browsers cannot call it directly (you need gRPC-Web or a gateway), binary payloads are harder to inspect, and public third-party developers prefer REST.
• REST: larger payloads, no built-in streaming, and the contract is looser unless you add OpenAPI.

A practical rule

Situation	Choose
Public API, browser clients, third parties	REST (or GraphQL)
Internal service-to-service calls with high volume	gRPC
Streaming data between services	gRPC
Quick prototype or simple CRUD	REST

Many systems use both: REST at the edge for outside clients, gRPC between internal services, with an API gateway translating.

Takeaway: default to REST for public APIs, and consider gRPC for internal, performance-sensitive or streaming calls.

---

System Design series, Part 2 (building blocks): topic 7 of 14. Previous: WebSocket vs Server-Sent Events vs long polling.