REST vs gRPC

HTTP/JSON resources vs typed, binary RPC over HTTP/2. REST is universal, cacheable, and browser-friendly; gRPC is efficient, typed, and streaming-capable for internal service-to-service calls. Not mutually exclusive — use a gateway to expose gRPC as REST.

Dimension	REST	gRPC
Contract	Implicit; documented via OpenAPI.	Strong, codegen from .proto.
Wire format	JSON (human-readable, larger).	Protobuf binary (compact, fast).
Transport	HTTP/1.1 or HTTP/2; cacheable.	HTTP/2 multiplexed; not browser-native.
Streaming	Via SSE/WebSockets (separate).	Built-in server/client/bidi streaming.
Best fit	Public APIs, browser clients, cacheable resources.	Internal service-to-service, typed contracts.

Contract

REST: Implicit; documented via OpenAPI.
gRPC: Strong, codegen from .proto.

Wire format

REST: JSON (human-readable, larger).
gRPC: Protobuf binary (compact, fast).

Transport

REST: HTTP/1.1 or HTTP/2; cacheable.
gRPC: HTTP/2 multiplexed; not browser-native.

Streaming

REST: Via SSE/WebSockets (separate).
gRPC: Built-in server/client/bidi streaming.

Best fit

REST: Public APIs, browser clients, cacheable resources.
gRPC: Internal service-to-service, typed contracts.

When REST wins

Public APIs and browser-facing endpoints.
You want HTTP caching and broad interoperability.

When gRPC wins

Internal service-to-service calls with a typed contract.
You need streaming or high throughput between services.

Verdict

Use gRPC inside your service mesh for efficiency and typing; expose REST (or gRPC-Web/Connect) at the edge for clients. They serve different layers, not the same job.