GraphQL, REST, or gRPC: Match the Protocol to the Caller

REST's alignment with HTTP semantics, caching via standard headers, predictable status codes, resource-oriented URLs anyone can read, makes it the right default for a public or partner-facing API where the caller isn't a system you control. Documentation tooling and client generation are mature and widely understood outside your own engineering org, which matters when your callers are third-party developers who won't read a schema definition to figure out how your API works. The cost is over-fetching and under-fetching: a mobile client often gets more or less data than it needs per endpoint, which is the problem GraphQL was built to solve.

Binary serialization over Protocol Buffers and HTTP/2 multiplexing give gRPC real latency and throughput advantages for high-volume internal calls between services you control on both ends. Strongly typed contracts generated from a shared `.proto` file catch mismatches at compile time instead of in production. The tradeoff is tooling friction at the edges: browsers don't speak gRPC natively without a proxy layer like gRPC-Web, and debugging a binary payload by eye is harder than reading a JSON response in a browser's network tab. Reach for it where both ends are services you own and latency actually matters.

GraphQL earns its place when a single client, often a mobile app or a dashboard, needs to combine data from several backend sources in one request and the shape of that data varies by screen. The tradeoff most teams discover late is the N+1 query problem: a naive resolver that fetches a list, then makes a separate database call per item to resolve a nested field, turns one logical request into dozens of database round trips. A dataloader pattern that batches and caches those per-item fetches within a single request is not optional at any real scale, it's a prerequisite for using GraphQL responsibly.

Every one of these protocols can silently break a caller if a field changes type or a response shape changes without warning: a REST endpoint that adds a required field, a `.proto` file changed without respecting backward-compatible field numbering, a GraphQL schema that deprecates a field consumers still query. Contract testing, verifying a service's actual responses against its published schema, catches this in CI before a caller does in production, and it's the one piece of governance that applies identically regardless of which protocol you've picked.

The pattern that works: pick REST or GraphQL at the edge, whichever fits your primary client's needs, and gRPC internally between services, with a gateway translating at the boundary if needed. What doesn't work is letting individual teams pick per-service based on preference with no shared convention; that's how you end up with five different pagination schemes and no one able to reason about the system as a whole. The protocol choice matters less than having one team own the convention and enforce it in review.

A workable split by caller:

• Public and partner APIs: REST, for standard HTTP caching, predictable status codes, and resource URLs anyone can read.
• Internal service-to-service calls: gRPC, for typed contracts from a shared proto file and HTTP/2 multiplexing.
• Aggregation for a mobile app or dashboard: GraphQL, with dataloader batching to keep the N+1 query problem in check.
• A gateway translating at the boundary, with one protocol convention per layer instead of a choice per team.

Protocol Buffers' binary encoding is smaller on the wire than the equivalent JSON, and HTTP/2 multiplexing avoids the head-of-line blocking that plain HTTP/1.1 REST calls can suffer under high concurrency; for high-volume internal traffic between services, this difference shows up as real, measurable latency and bandwidth savings, not just a theoretical one. For a low-volume public API where a human developer is reading the response in a browser during integration, the readability of plain JSON over REST usually outweighs any bandwidth savings a binary format would offer, which is part of why the right choice depends so heavily on who's actually consuming the response.

REST's tooling ecosystem, API documentation generators, client libraries in every language, browser-based debugging, is the most mature of the three simply by virtue of age and ubiquity, which matters more for a small team that can't afford to build custom tooling around a newer protocol's gaps. GraphQL and gRPC both have strong tooling now, but a small team evaluating them should weigh the learning curve and the time it takes to get a new engineer productive against the specific performance or aggregation benefit they're chasing, since that tradeoff often favors REST until a concrete pain point justifies the switch.