What is the difference between REST and gRPC?
Quick Answer
REST is resource-oriented over HTTP with JSON — human-readable, universally supported, easy to debug. gRPC is contract-first RPC over HTTP/2 with Protobuf — compact binary payloads, code-generated clients, built-in streaming, and lower latency. Use REST for public / browser-facing APIs; gRPC for internal service-to-service communication where performance matters.
REST is resources and verbs over HTTP with JSON — anyone can call it, you can debug it with curl, and browsers speak it natively. gRPC is remote procedure calls over HTTP/2 with Protobuf binary payloads. You define the service in a .proto file and generate strongly typed clients and servers, the messages are much smaller, and it has real streaming built in. The trade-off is it's harder to debug and browsers can't call it directly without a proxy. So I use gRPC between internal services where throughput and latency matter, and REST for anything a browser or an external partner talks to.
| REST | gRPC | |
|---|---|---|
| Payload | JSON (text) | Protobuf (binary) |
| Contract | OpenAPI (optional) | .proto (required) |
| Streaming | Limited (SSE) | Bidirectional, first-class |
| Browser support | Native | Needs grpc-web + proxy |
| Debuggability | curl / browser | Needs tooling |
gRPC shines for microservice meshes and real-time streams; REST for anything a browser or third party consumes.