REST vs gRPC vs GraphQL

REST, gRPC and GraphQL are three ways to design APIs, and each fits a different job. REST models resources over plain HTTP and is the easiest to adopt, cache and consume; it’s the default for public APIs. gRPC is a remote procedure call framework using HTTP/2 and Protocol Buffers, ideal for fast, strongly typed calls between internal services. GraphQL exposes a typed schema that clients query for exactly the data they need, which suits front ends with many different screens. Many systems use more than one.

REST

REST (representational state transfer) organises an API around resources, identified by URLs, and manipulated with standard HTTP methods: GET /orders/42, POST /orders, PATCH /orders/42. Responses are usually JSON, and HTTP status codes signal outcomes.

Strengths

• Works with every language, tool, proxy and browser.
• Uses HTTP’s built-in semantics, including caching, conditional requests and content negotiation (RFC 9110).
• Easy to explore and debug with a browser or command-line client.
• Contracts can be documented with OpenAPI.

Weaknesses

• Over-fetching and under-fetching: a screen may need three requests, each returning more fields than it uses.
• No built-in schema enforcement unless you add one.
• Real-time updates need extra machinery, such as WebSockets or server-sent events.

gRPC

gRPC is an open-source RPC framework originally developed at Google. You define services and messages in a .proto file; tooling generates client and server code in many languages. Calls travel over HTTP/2 as compact binary Protocol Buffers.

Strengths

• Efficient: small binary payloads and multiplexed connections.
• Strongly typed contracts with generated clients, so mismatches surface at build time.
• Streaming: server, client and bidirectional streams, as well as simple request-response calls.
• Deadlines and cancellation propagate across service calls.

Weaknesses

• Browsers can’t call gRPC directly; you need gRPC-Web and a proxy, or a REST gateway.
• Binary payloads are harder to inspect by hand.
• HTTP caching and many generic tools don’t apply.

GraphQL

GraphQL, developed at Facebook and open-sourced in 2015, is a query language plus a typed schema. Clients send a query describing exactly the fields they want, usually to a single endpoint, and get back JSON in the same shape.

query {
  order(id: 42) {
    status
    total
    customer { name }
    items { name quantity }
  }
}

Strengths

• One round trip for data that would take several REST calls.
• No over-fetching: clients choose their fields.
• A self-documenting schema with strong tooling, and subscriptions for real-time updates.
• Front-end teams can evolve screens without new endpoints.

Weaknesses

• The N+1 problem: naive resolvers make one database query per item; batching (for example with a DataLoader) is essential.
• Caching is harder: most queries are POST requests to one URL, so HTTP caching needs persisted queries or client-side caches.
• Expensive queries: clients can ask for deeply nested data, so you need depth and complexity limits.
• More server complexity than a simple REST API.

Side-by-side

Cross-cutting concerns

Whatever you choose, the same problems need solving:

• Rate limiting. Per-client limits protect every API style; GraphQL often needs limits by query cost rather than request count. See rate limiting algorithms.
• Retries and duplicates. Clients retry on timeouts, so make writes safe to repeat with idempotency keys.
• Caching. REST can lean on HTTP caches and CDNs; all three benefit from server-side caching (see caching strategies).
• Versioning. REST often versions URLs or headers; gRPC relies on backward-compatible Protocol Buffer changes; GraphQL prefers evolving the schema and deprecating fields.
• Errors. REST uses HTTP status codes; gRPC has its own status codes; GraphQL usually returns errors alongside partial data, so clients must check both.

How to choose

• Public or partner API: REST, possibly with an OpenAPI specification. Everyone can use it.
• Internal service-to-service traffic with tight latency budgets: gRPC.
• Web and mobile apps with many screens that combine data from several sources: GraphQL, often as a gateway in front of REST or gRPC services.
• Small team, simple product: REST. Don’t add a schema layer you don’t need yet.

A common architecture uses gRPC between internal services, with a REST or GraphQL layer at the edge for clients. How many services you have matters too; our microservices vs monolith framework helps decide whether you need internal APIs at all.

Frequently asked questions

Is gRPC faster than REST?

Usually, for service-to-service calls: binary payloads and HTTP/2 multiplexing reduce overhead. For many public APIs, network latency and database work dominate, so the difference matters less.

Does GraphQL replace REST?

No. It solves a different problem, flexible client queries, and it often sits in front of existing REST or gRPC services.

Can I use more than one?

Yes, and many companies do: gRPC internally, REST for public APIs and GraphQL for their own front ends.