API Styles: REST vs GraphQL vs gRPC

Three dominant API styles in 2026, each with distinct sweet spots.

REST over HTTP plus JSON — the ubiquitous default

• Resource-based: URLs identify things, verbs act on them
• JSON is human-readable; tooling is everywhere
• HTTP semantics free: status codes, caching, content negotiation
• Schemas via OpenAPI, optional
• Scales from tiny to massive
• Downsides: verbose payloads, multiple round-trips for complex views, over-fetching (returns fields client doesn't need), under-fetching (missing nested data)

GraphQL — Facebook's query language, open-sourced 2015

• Single endpoint accepting a query
• Client specifies exactly what fields it wants, including nested
• One request returns exactly that shape
• Strong schema; introspection; rich tooling like GraphiQL and Apollo Studio
• Downsides: query cost unpredictable; N+1 problem without DataLoader; HTTP caching breaks (POST with body); server complexity; learning curve

gRPC — Google, 2015

• HTTP/2 plus Protobuf: binary, compact, 3 to 10x smaller than JSON
• Strongly typed; compiled stubs in multiple languages
• Four modes: unary, server streaming, client streaming, bidirectional
• Deadlines, metadata, interceptors
• Downsides: not browser-friendly without gRPC-Web proxy; harder debugging (binary wire); schema discipline required

When to pick each

REST when

• Public API or B2B partners
• Simple CRUD services
• HTTP caching matters
• Team new to microservices
• Lowest learning curve

GraphQL when

• Mobile app with many screens needing varying data
• BFF aggregating many services
• Rapidly changing clients (web, iOS, Android teams evolve independently)
• Complex nested resources
• Avoiding over-fetching expensive fields

gRPC when

• Internal service-to-service at high volume
• Polyglot teams needing type safety
• Streaming use cases: telemetry, chat, financial feeds
• Strict latency budgets
• Schema-first team culture

The hybrid reality

• REST at the edge for public APIs and simple endpoints
• GraphQL BFF for complex frontends
• gRPC between internal services
• Events on Kafka for async decoupling

Key concepts

Over-fetching and under-fetching are REST's core weakness

• REST returns whole resource; client uses 10% of fields
• Or client needs user plus orders plus items; three round trips
• GraphQL asks client to specify; eliminates both

N+1 problem is GraphQL's curse

• Query like 'posts { author { name } }' with 100 posts can run 101 queries
• DataLoader batches author lookups into one query
• Mandatory, not optional

Query complexity analysis is GraphQL's rate-limiting answer

• Client can write arbitrarily expensive queries
• Analyze complexity; reject beyond limit; max depth
• Persisted queries: only allow pre-registered query hashes from clients

HTTP caching works with REST, breaks with GraphQL

• GraphQL POST with body can't be CDN-cached
• Persisted queries plus GET with hash enable CDN caching
• Apollo Response Cache, client-side normalized cache (Apollo Client, Relay)

Protobuf schema evolution discipline

• Adding fields safe; removing dangerous; never renumber
• Reserve tag numbers for removed fields
• Schema in shared repo with CI breakage checks (Buf)

gRPC-Web needs proxy

• Browsers don't natively speak gRPC over HTTP/2 frame access
• Envoy proxy translates; gRPC-Web has subset (no client streaming)
• Adds moving piece but solvable

Versioning approaches

• REST: URL (/v1/users, /v2/users) or header-based; common
• GraphQL: schema evolution via @deprecated; no hard versions
• gRPC: Protobuf field numbers; additive evolution safe

Tracing and observability

• REST: standard; every APM supports
• GraphQL: needs per-resolver instrumentation; OpenTelemetry GraphQL extension
• gRPC: spans via interceptor; OpenTelemetry first-class support

Anti-patterns

• GraphQL for simple CRUD: overkill; REST simpler
• gRPC for public API: browsers struggle; partners lack tooling
• REST with chatty calls: introduce batch endpoint or GraphQL BFF
• GraphQL without DataLoader: N+1 kills performance
• Protobuf renumbering: breaks all clients

The 2026 default recommendations

• Public API: REST with OpenAPI
• Internal microservices: gRPC
• Mobile or SPA BFF: GraphQL
• Real-time: gRPC bidirectional or WebSocket
• Mixed architecture: combine all three, each where it fits

The strategic answer

• No religious war; pick based on use case
• REST for simplicity and ubiquity
• GraphQL for field-selection needs and BFF
• gRPC for internal performance and type safety
• Real systems combine all three; architecture matches where each excels