What is the difference between gRPC and REST?
Compare gRPC and REST: Protobuf vs JSON, HTTP/2 vs HTTP/1.1, streaming, typing and caching, with examples and guidance on when to use each.
Expected Interview Answer
gRPC is a contract-first RPC framework using Protocol Buffers over HTTP/2, while REST is an architectural style that typically exchanges JSON over HTTP/1.1 using resource URLs and HTTP verbs.
gRPC emphasizes calling remote procedures with strongly-typed, generated stubs, compact binary payloads, and native bidirectional streaming, making it ideal for low-latency internal service-to-service communication. REST is resource-oriented, human-readable, cache-friendly and universally supported by browsers and tools, making it a strong fit for public APIs. The choice is about trade-offs: performance and typing versus ubiquity and simplicity.
- gRPC: faster binary payloads and lower latency
- gRPC: strong typing via generated code
- gRPC: native streaming over HTTP/2
- REST: human-readable JSON and easy debugging
- REST: broad browser and tooling support
- REST: simple HTTP caching of GET responses
AI Mentor Explanation
REST is like signalling to the boundary with clear, universally understood hand gestures anyone in the crowd can read. gRPC is like the fielders' private coded calls: faster and denser between teammates who share the playbook, but meaningless to an outsider who never agreed the code beforehand.
Step-by-Step Explanation
Step 1
Compare the paradigm
REST is resource-oriented around URLs and verbs; gRPC is procedure-oriented around service methods.
Step 2
Compare the payload
REST commonly uses text JSON; gRPC uses compact binary Protocol Buffers.
Step 3
Compare the transport
REST usually runs on HTTP/1.1; gRPC requires HTTP/2 for multiplexing and streaming.
Step 4
Compare typing
gRPC generates strongly-typed stubs from .proto files; REST typically relies on looser, documented JSON schemas.
Step 5
Choose per use case
Pick gRPC for internal high-performance services, REST for public, browser-facing, cache-friendly APIs.
What Interviewer Expects
- Clear distinction between RPC and resource-oriented styles
- Awareness of binary Protobuf versus text JSON
- Knowledge of HTTP/2 versus HTTP/1.1 implications
- Understanding of streaming support differences
- Ability to pick the right tool per scenario
Common Mistakes
- Claiming one is universally better than the other
- Saying REST cannot use HTTP/2 or gRPC cannot use JSON
- Ignoring browser limitations that require gRPC-Web
- Forgetting REST's caching and human-readability advantages
- Overlooking gRPC's streaming and strong typing benefits
Best Answer (HR Friendly)
“REST and gRPC are two ways for software to talk over a network. REST sends easy-to-read messages and works everywhere, especially in browsers, while gRPC sends compact, fast messages best suited for high-speed communication between internal services.”
Code Example
REST (HTTP/1.1, JSON):
GET /users/42
200 OK
{ "id": 42, "name": "Ada" }
gRPC (HTTP/2, Protobuf):
service UserService {
rpc GetUser (GetUserRequest) returns (User);
}
// client stub: userService.GetUser({ id: 42 })Follow-up Questions
- When would you choose gRPC over REST?
- Why can't browsers call gRPC directly?
- How does Protobuf compare to JSON in size and speed?
- Can REST APIs also run over HTTP/2?
- What is gRPC-Web and why does it exist?
MCQ Practice
1. Which best describes REST's typical data format?
REST APIs most commonly exchange human-readable JSON text.
2. Which feature is native to gRPC but not to classic REST?
gRPC natively supports bidirectional streaming over HTTP/2, which classic REST does not.
3. A key advantage REST retains over gRPC for public APIs is?
REST is directly consumable by browsers and benefits from standard HTTP caching of GET requests.
Flash Cards
REST vs gRPC: data format? — REST usually JSON text; gRPC compact binary Protocol Buffers.
REST vs gRPC: transport? — REST often HTTP/1.1; gRPC requires HTTP/2.
REST vs gRPC: typing? — gRPC is strongly typed via .proto stubs; REST relies on looser JSON schemas.
When to prefer REST? — Public, browser-facing, cache-friendly APIs needing broad compatibility.