Skip to content

REST vs gRPC

1. Decision

Choose REST (over HTTP/JSON) for public-facing client APIs (mobile/web) where universal browser support, human readability, and standard tooling dominate; choose gRPC (over HTTP/2 & Protocol Buffers) for internal microservice-to-microservice communication where ultra-low latency, high throughput, strict contract schemas, and bidirectional streaming are required.

2. 30-Second Answer

REST (Representational State Transfer) is a resource-oriented architectural style communicating via HTTP/1.1 or HTTP/2 using human-readable text payloads (JSON/XML). It is the universal standard for public APIs due to browser compatibility, cacheability, and simple debugging. gRPC is a high-performance open-source RPC framework created by Google that operates over HTTP/2 using binary Protocol Buffers (Protobuf) for serialization. gRPC delivers 7x-10x faster serialization speed, up to 50% smaller payload sizes, strict strongly-typed contract definitions (.proto files), multiplexed TCP connection reuse, and native streaming capabilities (Client, Server, Bidirectional), making it ideal for internal microservice mesh topologies.

3. Decision Matrix

Option Best For Avoid When Latency Scalability Consistency Operational Complexity
REST (HTTP / JSON) Public APIs, web browser clients, third-party developer integration, caching via CDNs Ultra-low latency microservice communication, high-frequency internal RPCs, streaming Low to Medium (Text parsing & TCP handshake overhead) High (Stateless horizontal scale) Standardized HTTP status codes & verbs Low
gRPC (HTTP/2 + Protobuf) Internal microservice-to-microservice communication, mobile app backends, real-time streaming, polyglot services Public browser APIs (requires gRPC-Web proxy), human-readable debugging requirements Extremely Low (Binary serialization & HTTP/2 multiplexing) Very High (Low CPU/RAM per RPC) Strict contract enforcement via .proto schemas Medium (Protobuf generation tooling)

4. Selection Rules

Requirement Best Choice Rationale / Example
Public API for Web & Mobile Developers REST Standard HTTP/JSON supported natively by every browser, language, and CURL tool
Internal Microservice Mesh (East-West Traffic) gRPC Sub-millisecond latency, binary Protobuf efficiency, and auto-generated client SDKs
Bi-directional Real-Time Streaming gRPC Native HTTP/2 multiplexed streaming allows simultaneous client-server data flow
Strict Type-Safe Contract Code Generation gRPC .proto definitions generate strongly-typed client/server stubs in 10+ languages
CDN Edge Caching of GET Responses REST Standard HTTP headers (Cache-Control, ETag) supported out-of-the-box by CDNs
Polyglot Microservices (Go, Java, Python, C++) gRPC Central .proto repository eliminates manually written HTTP client wrappers

5. Tradeoffs

  1. Human-Readable Text (JSON) vs High-Performance Binary (Protobuf)
  2. Gain (REST): Easy debugging via cURL/Postman; inspectable network payloads.
  3. Lose (REST): CPU-intensive JSON string parsing and verbose byte payload size.
  4. Universal Browser Support vs Specialized Client Proxies
  5. Gain (REST): Works out-of-the-box in Javascript fetch() on all web browsers.
  6. Lose (REST): Higher latency compared to gRPC binary multiplexing.
  7. Strict Protobuf Schema Contracts vs Flexible Loose JSON Schemas
  8. Gain (gRPC): Compile-time type safety; breaking API changes detected immediately during build.
  9. Lose (gRPC): Requires managing a central .proto repository and code generation CI/CD pipelines.
  10. HTTP/2 Multiplexing vs HTTP/1.1 Head-of-Line Blocking
  11. Gain (gRPC): Hundreds of concurrent requests multiplexed over a single TCP connection.
  12. Lose (gRPC): Requires L7 load balancers (Envoy) to distribute gRPC requests across pods evenly.
  13. Native Streaming vs Request-Response Polling
  14. Gain (gRPC): Unary, Client-Streaming, Server-Streaming, and Bidirectional Streaming supported natively.
  15. Lose (gRPC): Complex connection management and proxy configuration for web browsers (gRPC-Web).

6. Interview Counter Questions

  1. Why does gRPC serialization perform 7x-10x faster than REST JSON serialization?
  2. How does HTTP/2 multiplexing work in gRPC and why does it break traditional L4 Load Balancers?
  3. How do you handle Load Balancing for gRPC services using Envoy Proxy?
  4. How do Protocol Buffers maintain backward and forward compatibility during schema changes?
  5. What is gRPC-Web and why is it needed for browser applications?
  6. How does gRPC handle Deadline Propagation and Cascading Cancellations across microservices?
  7. What are the 4 streaming modes supported by gRPC?
  8. How does error handling differ between REST HTTP status codes and gRPC Status Codes?
  9. When would you choose REST over gRPC even for an internal microservice?
  10. How do you manage Protocol Buffer repository schemas across multiple engineering teams?

7. Gold Standard Answers

  1. Protobuf encodes data into compact binary tag-value pairs without field names or delimiter strings. Parsing binary integers requires simple CPU bitwise operations, avoiding expensive text string scanning and float parsing needed for JSON.
  2. HTTP/2 multiplexes multiple RPC streams over a single long-lived TCP connection. L4 load balancers route at the TCP connection level, directing all multiplexed requests to a single pod. L7 proxies (Envoy) parse HTTP/2 frames to balance individual RPCs across pods.
  3. Deploy Envoy Proxy as an L7 sidecar or ingress gateway. Envoy reads individual gRPC HTTP/2 stream headers and uses round-robin or least-request algorithms to distribute requests across backend pods.
  4. Protobuf uses field tags (string name = 1;). Field names can change, but field numbers must remain static. Unrecognized new field tags are ignored by old clients (backward compatible), and new clients receive default values for omitted fields (forward compatible).
  5. Web browsers cannot access low-level HTTP/2 framing required for native gRPC. gRPC-Web acts as a JS client library + proxy (Envoy) that translates browser HTTP/1.1 or HTTP/2 fetch requests into native gRPC calls.
  6. gRPC transmits grpc-timeout headers down the call chain (Service A \(\rightarrow\) B \(\rightarrow\) C). If Service A cancels the context or deadline expires, HTTP/2 RST_STREAM frames propagate down immediately, terminating wasted downstream work.
  7. Unary (1 Request \(\rightarrow\) 1 Response), Server-Streaming (1 Request \(\rightarrow\) Stream of Responses), Client-Streaming (Stream of Requests \(\rightarrow\) 1 Response), and Bidirectional Streaming (Stream \(\leftrightarrow\) Stream).
  8. REST uses HTTP status codes (200, 404, 500). gRPC uses 16 canonical integer status codes (OK, NOT_FOUND, UNAUTHENTICATED, DEADLINE_EXCEEDED, UNAVAILABLE) defined in the grpc/status.h spec.
  9. Choose REST internally when team familiarity dominates, infrastructure lacks L7 proxy support, payload inspection via cURL is required, or integration involves legacy systems without Protobuf support.
  10. Maintain a central Git repository for .proto definitions (e.g., Buf Schema Registry). CI/CD pipelines automatically validate breaking changes (buf breaking) and publish generated SDK packages to internal package managers (npm, Maven, PyPI).

8. Common Mistakes

  • Placing a standard L4 TCP Load Balancer in front of gRPC microservices, causing 100% of traffic to pin to a single pod.
  • Renaming or re-using Protobuf field tag numbers (= 1), causing severe binary deserialization corruption.
  • Exposing raw gRPC endpoints directly to web browser clients without gRPC-Web or an API Gateway translation layer.
  • Failing to configure gRPC deadlines (context.WithTimeout), resulting in hanging microservice threads under downstream latency spikes.
  • Using REST JSON for internal high-throughput microservices (>50,000 RPC/sec), burning massive CPU on text serialization.

9. Keywords

REST, gRPC, Protobuf, Protocol Buffers, HTTP/2, Multiplexing, Head-of-Line Blocking, L7 Load Balancing, Envoy Proxy, gRPC-Web, Deadline Propagation, RST_STREAM, Canonical Status Codes, Buf Schema Registry, Unary, Bidirectional Streaming.

10. Cheat Sheet

  • Core Distinction: REST = Public HTTP/JSON (Human-readable, browser native, universal); gRPC = Internal HTTP/2 Protobuf (Binary, ultra-fast, type-safe).
  • Performance: gRPC is 7x–10x faster and up to 50% smaller payload size than REST JSON.
  • Load Balancing Rule: gRPC requires L7 Load Balancing (Envoy Proxy) due to HTTP/2 long-lived multiplexed TCP connections.
  • Protobuf Rules: Never change tag field numbers (= 1). Add new fields as optional/new tags for backward/forward compatibility.
  • Resilience: Always set gRPC Deadlines (WithTimeout) to propagate context cancellations across microservices.
  • Tooling: Use Buf for .proto linting, breaking-change detection, and automated client SDK code generation.

11. Related Decisions