Overview
REST is the lingua franca of the web: resources, JSON, plain HTTP, debuggable with curl and cacheable by any proxy. gRPC trades that universality for performance — you define your API in a .proto file, generate typed clients and servers in many languages, and messages travel as compact binary Protobuf over multiplexed HTTP/2 with first-class streaming. The split is usually browser-facing/public (REST) versus internal microservice-to-microservice (gRPC).
REST vs gRPC: key differences
| REST | gRPC | |
|---|---|---|
| Payload | JSON text (human-readable) | Protobuf binary (compact, fast) |
| Transport | HTTP/1.1 (or 2) | HTTP/2 (multiplexed) |
| Contract | Optional (OpenAPI) | Strict .proto schema + codegen |
| Streaming | Awkward (SSE/chunked) | Native bi-directional streaming |
| Browser support | Native everywhere | Needs gRPC-Web proxy |
When to use REST
Public APIs, browser clients, simple CRUD, when HTTP caching and broad tooling matter, or when you want anyone to call your API with no special client.
When to use gRPC
Internal east-west traffic between microservices where latency and payload size matter, polyglot teams that benefit from generated typed stubs, or streaming RPCs.
Verdict
Default to REST at the edge — it is universal, cacheable and easy to debug. Use gRPC between your own services where the performance, streaming and strong contracts pay off and you control both ends. Many systems expose REST publicly and speak gRPC internally.
Common questions
Is gRPC faster than REST?
Usually yes for service-to-service calls: binary Protobuf is smaller than JSON and HTTP/2 multiplexes many calls over one connection, cutting latency and overhead. The gap is largest under high call volume; for occasional requests it rarely matters.
Can I use gRPC in a browser?
Not directly — browsers cannot speak raw gRPC. You need gRPC-Web plus a proxy (Envoy) that translates. For browser-facing APIs, REST or GraphQL is typically simpler.