What you'll learn
Quick Answer
REST sends JSON over HTTP and works everywhere with zero tooling. gRPC sends binary Protocol Buffers over HTTP/2, generates typed client and server code from a schema, and supports streaming - but browsers cannot call it directly without a proxy. Use REST for public APIs and anything a browser hits; use gRPC for internal service-to-service traffic where latency and type safety matter.
The two shapes
A REST endpoint is a URL and an HTTP method. You GET /users/42, the server returns JSON, and any HTTP client - curl, a browser, Postman - can call it with no setup. The contract is informal: it lives in documentation, and the client and server agree to keep field names in sync by convention.
gRPC starts from a schema file. You write a .proto describing the service and its messages:
service Greeter {
rpc SayHello (HelloRequest) returns (HelloReply);
}
message HelloRequest { string name = 1; }
message HelloReply { string message = 1; }A code generator turns that into a typed client and a server stub in your language. Calling the API looks like calling a local function: client.SayHello({ name: 'Priya' }). The request and response travel as compact binary Protocol Buffers over HTTP/2, not as text.
The trade is upfront: gRPC gives you a machine-checked contract and smaller, faster messages, but you have to run a build step and distribute generated code. REST gives you nothing to build and universal reach, at the cost of a contract nothing enforces.
On the wire: binary vs text
JSON is human-readable and self-describing - every message repeats its field names as strings. Protocol Buffers drop the names entirely. A field is identified by the number you assigned it in the .proto (name = 1), and values are packed in a binary layout. For a message with many small fields, the Protobuf encoding is often several times smaller than the equivalent JSON.
gRPC also mandates HTTP/2, which multiplexes many calls over one connection and avoids repeatedly paying the TCP and TLS handshake cost. REST can use HTTP/2 as well, but in practice a lot of REST traffic is still HTTP/1.1 with a new connection per request or a small connection pool.
The result is that gRPC usually wins on raw throughput and tail latency for chatty internal traffic - a service that makes hundreds of small calls to another service per request. For a public API where each client makes a handful of calls and the payloads are already small, the difference is rarely what limits you; network round-trips and database time dominate.
Streaming is built in
REST models one request and one response. Anything continuous - a live feed, progress updates, a chat - needs a bolt-on: Server-Sent Events, WebSockets, or polling.
gRPC has four call types in the protocol itself: unary (one in, one out), server streaming (one in, many out), client streaming (many in, one out), and bidirectional streaming (both sides send freely over one connection). You declare the shape in the .proto with the stream keyword, and the generated code hands you an async iterator or a writable stream.
If your system genuinely needs long-lived streams between services - telemetry pipelines, real-time sync, large result sets you want to process as they arrive - gRPC gives you that without inventing a second transport. This is one of the clearest reasons to reach for it.
The browser gap
This is the constraint that decides most architectures. A browser cannot make a native gRPC call. The Fetch API does not expose the low-level HTTP/2 frame control that gRPC needs, so a web page cannot talk to a gRPC server directly.
The workaround is gRPC-Web, a variant that runs over normal HTTP and requires a proxy - usually Envoy or a small in-process translator - sitting between the browser and the real gRPC service. It works, but it adds a component to deploy and monitor, and gRPC-Web does not support client streaming or bidirectional streaming.
So the common pattern is: browsers and third-party clients hit a REST (or GraphQL) gateway; that gateway and everything behind it speak gRPC to each other. You get REST's reach at the edge and gRPC's speed and typing on the inside, at the cost of maintaining the translation layer.
Errors and day-to-day debugging
REST leans on HTTP status codes you already know - 200, 404, 500 - plus a JSON error body you design. When something breaks you can curl the endpoint, read the response in your terminal, and paste it into a bug report.
gRPC has its own status code set: OK is 0, NOT_FOUND is 5, DEADLINE_EXCEEDED is 4, UNAVAILABLE is 14. These are richer and more consistent than HTTP codes, but you cannot inspect a binary Protobuf frame by eye. You need grpcurl, a plugin for your API client, or logging on the server to see what actually went over the wire.
The gotcha: teams new to gRPC underestimate this friction. Every quick "let me just hit the endpoint and see" now needs a tool and the compiled proto. Budget for that in developer time, especially for on-call engineers debugging at 3am.
Which to choose
Reach for REST when: the API is public or consumed by teams you do not control; a browser calls it directly; the payloads are already small and human-readable debugging matters; or you simply want to ship without a build step and schema-distribution story.
Reach for gRPC when: the traffic is internal service-to-service and high-volume; you want a contract the compiler enforces across many services in different languages; you need real streaming; or you are already running a service mesh where gRPC is the norm.
Plenty of systems use both, and that is fine - REST at the edge, gRPC between services. What rarely pays off is adopting gRPC for a small app with one frontend and one backend: you take on the tooling cost and get little of the benefit, because your bottleneck was never serialization.