REST vs GraphQL vs gRPC: Choosing the Right API Protocol
Every API starts with a choice that will shape every decision that follows: what protocol are you building on? REST, GraphQL, and gRPC are the three dominant options in modern API development, and none of them is universally correct. Each reflects a different set of assumptions about who is calling the API, how often, and what they need back.
Understanding the tradeoffs is not optional knowledge for serious API developers. It is the foundation.
REST: The Default for Good Reason
REST (Representational State Transfer) is not a protocol — it is an architectural style. It uses HTTP as its transport layer and organizes APIs around resources: things rather than actions. A REST API for a bookstore has endpoints like /books, /books/{id}, and /authors/{id}/books. You GET, POST, PUT, PATCH, and DELETE against those resources using the verbs HTTP already provides.
REST is the default choice for public APIs because it is universally understood, works with every HTTP client in existence, and maps cleanly to the mental model most developers already have. Browser tooling, caching infrastructure, API gateways, and monitoring systems are all built with REST in mind.
The weakness is over-fetching and under-fetching. A REST endpoint returns what it returns — if you need five fields from a response with fifty, you still get fifty. If you need data from three resources, you make three requests. For simple CRUD applications this barely matters. At scale, or on mobile networks, it does.
GraphQL: Query What You Actually Need
GraphQL flips the model. Instead of the server defining what each endpoint returns, the client specifies exactly what it wants. A single /graphql endpoint accepts structured queries that describe the shape of the desired response. You ask for the fields you need, nested relationships and all, and you get exactly that back.
This solves over-fetching and under-fetching cleanly. It also makes it straightforward to evolve APIs without versioning — you add fields, deprecate old ones, and clients ask for what they support. Facebook built GraphQL to manage the explosion of clients (web, iOS, Android, third-party integrations) all needing slightly different slices of the same underlying data.
The tradeoffs are real. GraphQL queries require more complexity on both sides: the server needs a resolver layer and a schema, and the client needs to construct valid queries rather than just hitting a URL. Caching, which is nearly free with REST, becomes a deliberate engineering problem with GraphQL. And debugging a failing GraphQL query is materially harder than debugging a 404.
GraphQL earns its complexity when you have multiple client types with divergent data needs, or when your data model is deeply relational and REST endpoints would require too many round trips.
gRPC: Speed Over Convenience
gRPC is built on HTTP/2 and uses Protocol Buffers (protobuf) to serialize data. Where REST sends JSON — human-readable, relatively large — gRPC sends binary-encoded messages that are faster to serialize, smaller on the wire, and strictly typed by a schema defined in .proto files.
The result is significantly faster communication, built-in bidirectional streaming, and strong contracts enforced at compile time. If your REST API and gRPC API carry equivalent data, the gRPC version will be meaningfully faster and smaller. For internal microservice communication at high volume, that difference compounds.
What gRPC sacrifices is accessibility. You cannot call a gRPC API from a browser without a proxy layer. You cannot inspect requests in your browser’s network tab. You cannot use curl to test it. The tooling ecosystem is narrower, and onboarding new developers takes longer because protobuf schemas and generated clients are an additional layer most web developers have not worked with.
gRPC is the right choice for internal service-to-service communication, especially where performance is critical. It is the wrong choice for a public API that external developers need to integrate quickly.
The Practical Decision Matrix
If you are building a public API that external developers will consume: use REST. The integration barrier matters more than the performance ceiling at this stage, and REST’s familiarity means developers can get a working integration running in minutes rather than hours.
If you are building a product with multiple client types (web, mobile, third-party) that all need different slices of a complex data model: GraphQL pays off the complexity cost. Expect to invest in schema design and resolver architecture upfront.
If you are building internal microservice infrastructure where services talk to each other at high frequency and you control both ends of the connection: gRPC is worth the tooling investment. The performance gains are real and the schema enforcement reduces a category of integration bugs.
Many production systems use more than one. A public REST API for external developers, GraphQL for the internal frontend, and gRPC for the services those APIs sit on top of is not an unusual architecture. The protocols are tools, not religions. Learn all three well enough to choose deliberately.