REST vs gRPC

REST and gRPC represent different generations of API design. REST is the dominant paradigm for public APIs, built on HTTP and JSON. gRPC is a high-performance RPC framework from Google that uses Protocol Buffers and HTTP/2 to optimize internal service communication.

Serialization and Performance

The single biggest difference is the wire format. REST typically uses JSON — human-readable but verbose. gRPC uses Protocol Buffers, a binary format that is roughly 10x faster to serialize/deserialize and produces payloads 3-5x smaller.

For a service handling millions of inter-service calls per second, this difference compounds into significant CPU and bandwidth savings.

Streaming Capabilities

gRPC natively supports four communication patterns: unary (request-response), server streaming, client streaming, and bidirectional streaming. REST is limited to request-response; real-time features require bolting on WebSockets or Server-Sent Events.

The Browser Problem

gRPC's biggest limitation is browser support. Browsers cannot make HTTP/2 requests with trailers, which gRPC requires. The gRPC-Web project bridges this gap with a proxy layer, but it adds complexity and only supports unary and server streaming.

This is why most architectures use gRPC internally and expose REST (or GraphQL) at the edge. See our API Gateway concept for patterns that bridge the two.

Contract-First Development

gRPC enforces a contract-first approach through .proto files. Both client and server code are generated from the same schema, making version mismatches impossible. REST can achieve this with OpenAPI, but it requires discipline to keep specs in sync.

Explore related microservices interview questions and our system design interview guide. For full access to mock interviews, see our pricing.

The Bottom Line

Use REST for public APIs and browser-facing services. Use gRPC for internal microservice communication where performance, streaming, and type safety are critical.