REST vs GraphQL vs gRPC

Choose by who the clients are, how varied their needs are, and whether browsers and caches must understand the traffic.

Choosing an API style means matching its trade-offs to the integration's clients. REST reaches every client and works with HTTP caches; GraphQL lets varied clients take exactly the data they need; gRPC gives fast, strongly typed calls between services. Many systems use more than one: gRPC between internal services, with REST or GraphQL at the edge.

Each property across the three styles
Property	REST	GraphQL	gRPC
Who shapes the response	The server, per resource	The client, per query	The server, per procedure
HTTP caching	Built in, per URL	Needs extra work	Not by HTTP caches
Contract and typing	Optional, such as OpenAPI	A required, typed schema	A required .proto, with generated code
Browser clients	Native	Native	Needs gRPC-Web and a proxy
Payload size and speed	Larger, text	Fits the query, text	Small, binary, over HTTP/2
Streaming	Server-sent events or WebSockets alongside	Subscriptions, usually over WebSockets	Built in, four shapes
Evolution	Versions or additive changes	Add fields, deprecate old ones	New field numbers, reserved old ones
Ease of trying by hand	curl and a browser	An explorer such as GraphiQL	Needs a gRPC tool
Typical fit	Public and partner APIs	Front ends with many varied screens	Internal service-to-service calls

Choose REST when the clients are many and unknown, such as partners and the public, when caching matters, and when anyone should be able to try the API with curl.

Choose GraphQL when one team builds front ends with many screens over the same data, and the cost of a request per resource, or of a custom endpoint per screen, has become the bottleneck.

Choose gRPC when both ends are services the team owns, calls are frequent, payloads and latency matter, and streaming is needed.

So decide by the clients first; the style that suits them decides most of the rest.

← → move through sections and cards