A team is choosing between REST with JSON over HTTP/1.1 and gRPC over HTTP/2 for synchronous calls between two internal services. What concrete technical trade-offs should drive that decision?

## Two mechanisms, three axes of difference REST over HTTP with JSON and gRPC over HTTP/2 are both synchronous request-response mechanisms, but they differ in wire format, contract strictness, and transport capabilities in ways that matter a great deal once a system has dozens of services calling each other constantly. - **REST** typically means resources addressed by URL, standard HTTP verbs (`GET`, `POST`, `PUT`, `DELETE`), and a JSON body for the payload. JSON is plain text: human-readable, trivially inspectable with `curl` or a browser dev tools panel, and parseable by literally every programming language's standard library. - **gRPC** instead defines a service contract in a `.proto` file, specifying exact method names, request/response message shapes, and field types, then uses a code generator to produce client stubs and server skeletons in whatever languages you need. Those messages are serialized with Protocol Buffers, a compact binary encoding, and sent over HTTP/2 rather than HTTP/1.1. ## Why gRPC exists The reason gRPC exists is that JSON-over-HTTP/1.1 has real costs at scale that only show up once you're making a large volume of internal calls. - **Serialization cost.** JSON serialization and parsing is comparatively slow and CPU-heavy because it's text that has to be tokenized and type-inferred; protobuf's binary format skips most of that work and produces smaller payloads, which matters for both latency and network cost at high request volume. - **Connection cost.** HTTP/1.1 also opens one request per connection at a time (absent pipelining hacks most stacks don't use), so a client calling many endpoints either serializes requests or opens many connections; HTTP/2 multiplexes many concurrent requests and responses over a single connection, cutting connection overhead and enabling true streaming, including a client streaming many messages, a server streaming many responses, or both directions at once, none of which REST/JSON has a standard mechanism for. ## The other direction The trade-offs run in the other direction too. **JSON's human-readability is not a minor convenience:** being able to `curl` an endpoint and read the response directly, or inspect a request in a browser's network tab, is what makes REST APIs approachable for debugging, for third-party integrators, and for browser-based frontends, none of which can speak gRPC natively since browsers don't expose raw HTTP/2 trailers the way gRPC needs; you'd need a translation proxy like grpc-web or a REST gateway in front of the gRPC service. **REST's looser contract**, where the shape of the JSON is documented (often via OpenAPI) rather than compiler-enforced, is also a double-edged sword: it's easier to evolve informally (add an optional field, nobody's build breaks), but that same looseness means a typo'd field name or a subtly wrong type only fails at runtime, sometimes deep in production, rather than at compile time. gRPC's generated stubs catch a whole class of contract mismatches before the code ever runs, at the cost of needing coordinated codegen: both the calling service and the called service need to regenerate and redeploy code when the `.proto` contract changes, which is more process overhead than just updating a JSON example in a wiki page. ## Where the breakages cluster In production: | Choice | Where the trouble concentrates | |---|---| | **REST/JSON** | Failure modes tend to be about malformed or unexpected payloads slipping through at runtime, since there's no compiler to catch a client sending a string where the server code expects a number, and about the aggregate cost of serialization overhead showing up as CPU time in flame graphs once request volume gets high enough. | | **gRPC** | Failure modes tend to cluster around version skew, where an older client generated from an outdated `.proto` talks to a newer server (or vice versa), and around HTTP/2-specific infrastructure issues, since some older load balancers, proxies, and corporate firewalls don't handle HTTP/2 or gRPC's use of trailers correctly, which can manifest as mysterious connection resets that don't happen with plain HTTP/1.1. | ## Where the split usually lands A concrete, well-known real-world split: Google, which created both Protocol Buffers and gRPC, uses gRPC extensively for internal service-to-service calls across its own infrastructure where both ends are Google-controlled services and performance at massive scale matters, while public-facing Google APIs are generally still exposed as REST/JSON (or a REST-like interface) precisely because external developers need something they can read, debug, and call from a browser or a simple HTTP client without needing gRPC tooling installed. That same split, gRPC internally, REST/JSON at the edge or for public APIs, is the common pattern most organizations converge on rather than picking one universally.