Side by side
| Dimension | gRPC | REST |
|---|---|---|
| API model | gRPC: service methods and typed messages | REST: resources and HTTP semantics |
| Contract and tooling | Usually Protobuf definitions and generated clients | Often JSON with OpenAPI; client generation is optional |
| Transport | Standard gRPC uses HTTP/2 | Can use HTTP/1.1, HTTP/2, or HTTP/3 |
| Streaming | Unary, client, server, and bidirectional streaming | Request-response by default; SSE supports server push |
| Browser access | Typically requires gRPC-Web or another adapter | Direct support through browser HTTP APIs |
| Caching | Usually application-level caching | Cacheable GETs can use browsers, proxies, and CDNs |
| Performance | Compact messages can reduce serialization and wire costs | Depends on format, compression, transport, and workload |
| Operations | Needs gRPC-aware routing and status visibility | Fits common HTTP routing and inspection tools |
The differences that matter
gRPC makes the service contract central: define methods and messages, then generate client and server code. REST models resources with HTTP methods and status codes, often using OpenAPI for a typed contract. With either approach, rolling deployments require backward-compatible changes; Protobuf field numbers must not be reused.
gRPC provides client, server, and bidirectional streaming within its RPC model. A REST API can use server-sent events for one-way updates, while full-duplex browser communication commonly uses a separate WebSocket interface. Streaming still needs bounded buffers, slow-consumer handling, and reconnect rules.
A REST GET can use standard HTTP cache controls, validators, and shared caches when authorization and cache keys permit it. gRPC calls generally need application-level caching. For a public read-heavy API, this difference can matter more than smaller encoded messages.
gRPC's compact Protobuf encoding and reusable HTTP/2 connections can help communication-heavy workloads, but REST can also use HTTP/2, compression, and connection reuse. Long-lived gRPC channels require deliberate load balancing: a connection-level balancer may keep traffic pinned to a backend, while client-side balancing or an HTTP/2-aware proxy can distribute calls.
Choose gRPC when
- You control both clients and servers and want generated, typed clients across several programming languages.
- Internal services exchange many small messages, and measurements show serialization or network overhead is material.
- The interface needs client streaming or bidirectional streaming, and all clients support the chosen gRPC stack.
- Your infrastructure supports gRPC-aware routing, health checks, deadlines, and observability.
Choose REST when
- You expose an API to browsers, partners, or developers who need broad compatibility and easy manual inspection.
- The interface is naturally resource-oriented, such as retrieving products or updating account settings.
- Read traffic can benefit from HTTP caching, conditional requests, or CDN delivery.
- Simple request-response operations meet the requirements, and adding RPC-specific tooling would not solve a concrete problem.
A worked example
Public catalog API with internal service fan-out
Suppose a storefront receives 20,000 page requests per second, and each uncached request makes four internal calls. That creates up to 80,000 internal calls per second before retries. Use REST for the public catalog API so browsers can call it directly and eligible product reads can use HTTP caching. Consider gRPC between the gateway and pricing, inventory, and recommendation services when generated contracts and compact messages justify the tooling. Measure representative payloads rather than assuming a speedup. Give each internal call a deadline within the page latency budget, distribute calls across backends, and avoid automatically retrying inventory mutations without idempotency protection. Cache effectiveness may reduce more work than changing protocols.
In the interview
- Start with the client boundary: browser, mobile, partner, or internal service. REST externally and gRPC internally is a reasonable split, but explain the gateway and contract-maintenance cost.
- Tie performance claims to a workload: request rate, payload size, fan-out, and latency budget. Expect questions about whether encoding or database and network time actually dominates.
- Explain deadlines, cancellation, and retry budgets across service calls. Neither protocol makes a timed-out write safe to retry; mutations may need idempotency keys and stored results.
- For streaming, describe connection placement, load balancing, deployments, and reconnect behavior. Transport flow control does not replace application-level backpressure or durable replay.
Common mistakes
- Saying gRPC is always faster because REST uses HTTP/1.1. REST can use HTTP/2, and performance depends on the actual implementation and workload.
- Claiming REST cannot stream or that browsers directly support standard gRPC. Distinguish SSE, WebSockets, gRPC-Web, and native gRPC capabilities.
- Treating Protobuf as automatic compatibility. Removing fields, reusing field numbers, or changing application semantics can still break clients.
- Assuming a timeout means an operation did not execute, or that a gRPC stream provides durable delivery. Both designs need explicit retry, deduplication, and recovery semantics.
Where it comes up
Interview questions where choosing between gRPC and REST comes up.
- Design a ride hailing app like UberCompare external client APIs with internal location and matching RPCs, including streaming, deadlines, and connection routing.
- Design a metrics monitoring system like DatadogChoose ingestion interfaces based on client compatibility, batching, streaming, and backpressure rather than encoding alone.
- Design a distributed cacheA high-rate internal cache API makes serialization overhead, connection reuse, and per-call load balancing concrete design concerns.
- Design a weather appPublic weather reads highlight REST's HTTP caching advantages while allowing different protocols for internal aggregation calls.
Questions people ask
Is gRPC faster than REST?
It can be, particularly when compact Protobuf messages reduce serialization and transfer costs. But REST can also use HTTP/2, connection reuse, and compression. Compare representative workloads, including tail latency and CPU cost, rather than treating the protocol choice as a guaranteed speedup.
Can browsers call gRPC APIs directly?
Standard browser APIs do not expose everything needed for native gRPC. gRPC-Web provides browser access, often through a compatible proxy or server, but streaming support depends on the client and transport. For full-duplex browser communication, evaluate WebSockets rather than assuming native gRPC behavior.
Should microservices use gRPC or REST?
Use gRPC when controlled clients, generated contracts, or streaming justify it. Use REST when HTTP semantics, caching, accessibility, or simpler integration matter more. A system can use both, provided the boundary does not create unnecessary translation and operational complexity.