REST vs gRPC

NetworkingMidapinetworking

The Question

What is the difference between REST and gRPC?

What a Strong Answer Covers

• protobuf
• "HTTP/2
• "REST not limited to HTTP/1.1
• "gRPC for internal

Senior-Level Answer

REST (Representational State Transfer) and gRPC are both approaches for building networked APIs, but they make fundamentally different tradeoffs optimized for different contexts.

REST is an architectural style built on HTTP semantics: resources are identified by URLs, operations are expressed with HTTP verbs (GET, POST, PUT, DELETE, PATCH), and representations are typically JSON or XML. REST is stateless, cacheable (GET responses can be cached at HTTP layer), and leverages existing HTTP infrastructure. Its strength is interoperability and accessibility: any client that speaks HTTP can call a REST API without a generated client — browsers, curl, Python's requests, all work natively. REST APIs are self-documenting through URL structure and HTTP conventions, and humans can understand and debug them with basic tools.

gRPC is a Remote Procedure Call framework from Google, built on HTTP/2 and Protocol Buffers (protobuf). Instead of resources and verbs, you define services and methods in a `.proto` schema file. protoc generates strongly typed client and server stubs in your target language. Messages are binary-encoded (not human-readable text), making them ~5-7x smaller than equivalent JSON and faster to serialize/deserialize. HTTP/2 enables multiplexed streams over one connection, bidirectional streaming, and header compression.

The four communication patterns gRPC supports that REST doesn't match natively: unary RPC (one request, one response — REST equivalent), server streaming (one request, stream of responses — REST needs SSE/chunked), client streaming (stream of requests, one response), and bidirectional streaming (both sides stream independently — no REST equivalent without WebSockets).

When to choose REST: public-facing APIs where clients are diverse and unknown, APIs that benefit from HTTP caching, web browser clients (gRPC-Web exists but adds complexity), when developer experience and discoverability matter more than raw performance.

When to choose gRPC: internal service-to-service communication in microservices architectures, high-throughput low-latency APIs (real-time systems, ML inference), when you need strong typing and generated clients to reduce integration bugs across team boundaries, or when you need streaming.

Contract enforcement is a key gRPC advantage: the .proto file is a formal contract. Breaking changes are caught at code generation time. REST with OpenAPI approximates this, but JSON's dynamic nature means runtime type errors are more common.

Key Differences

What Separates a 2/3 from a 3/3

Common Mistakes

• Describing REST as strictly HTTP/1.1 — REST can use HTTP/2; gRPC requires HTTP/2.
• Not knowing Protocol Buffers at all — candidates who say 'gRPC uses binary format' without knowing it's protobuf miss the schema-first design advantage.
• Forgetting browser support as a meaningful REST advantage — this often decides the choice in practice.
• Not mentioning gRPC's streaming capabilities — unary gRPC vs REST is less interesting than the streaming patterns that have no REST equivalent.

Follow-Up Questions

• How does Protocol Buffers backward compatibility work? — Fields are numbered, not named, in the wire format. Adding new fields with new numbers is backward compatible. Changing field numbers or types is a breaking change.
• What is gRPC-Web and why is it needed? — Browsers can't use HTTP/2 trailers which gRPC requires. gRPC-Web is a modified protocol with an Envoy/nginx proxy translating between gRPC-Web and native gRPC on the server side.
• How would you handle authentication in gRPC? — Metadata (analogous to HTTP headers) carries auth tokens. Interceptors (middleware) on client and server side handle token attachment and validation consistently across all methods.
• Can you use REST and gRPC in the same system, and why might you? — Yes — REST for external/public-facing APIs where discoverability matters, gRPC for internal service mesh where performance and type safety are priorities. API gateway can translate.

Related Questions

• TCP — 3-Way Handshake
• TLS — Certificate, DH, AES
• TCP vs UDP
• HTTP vs HTTPS
• WebSockets