How does gRPC differ from REST APIs?

beginner

Re-explain

gRPC and REST differ mainly in the contract and the wire format. gRPC uses a strict Protocol Buffers contract, sends binary messages over HTTP/2 and streams in both directions. REST uses resources and HTTP verbs with JSON, which any browser or tool can read.

Aspect	gRPC	REST
Protocol	HTTP/2	HTTP/1.1 or HTTP/2
Data Format	Binary Protocol Buffers	Text JSON
Performance	Faster, lower latency	Slower due to text parsing
Streaming	Bidirectional streaming	Limited streaming support
Browser Support	Needs gRPC-Web	Native support
Caching	Limited caching capabilities	HTTP caching support
Learning Curve	Steeper	Gentler
Use Case	Microservices, real-time apps	Web APIs, CRUD operations

Choose gRPC for internal service-to-service calls where speed and typed clients matter. Choose REST for public and browser-facing APIs, where HTTP caching and plain JSON help more than raw speed.

Rewriting in plainer words…

This answer doesn't lend itself to a diagram - it reads best . No credits were charged.

Why there's no diagram: “”

The interactive diagram is below the answer - jump to diagram ↓ · Below it, the related concept . Jump to it ↓

The diagram below the answer is the concept . Jump to it ↓

Tailored explanation · switch back to · ·

What should the new diagram focus on?

Guided practice for API Design One question at a time. Answer out loud, get graded, see what you missed.

Related concept

Who controls the response shape

In REST the server decides the response shape, in GraphQL the client builds it, and in gRPC a compiled contract sets it. The trade-offs come from who decides the shape.

For this question · chapters 1 and 3 of 3gRPC and REST differ in the contract and in the wire format. Watch REST's fixed response shape send one screen extra fields but miss fields the screen needs. Then watch gRPC compile its contract from a .proto file and send binary over HTTP/2, so gRPC is fast between services but hard for browsers.

1/3 Over-fetching and under-fetching

Over-fetching and under-fetching

A profile screen needs its data in one exact shape. The screen has four rows: the name with its avatar, then the last three orders, each with a product name and a total. But the server that answers the request has never seen this screen. Every problem in this concept comes from the server not knowing that shape.
The first request shows over-fetching: the response is bigger than the screen needs. The call to GET /users/123 returns 24 fields in 2400 bytes, but the screen shows only two of them. The mobile radio still turns on to download the other 22 fields, which the screen never shows. The endpoint is not badly written: it is written once for every caller, and this screen is only one of those callers.
Under-fetching is the same mistake in the opposite direction. This time the fixed response shape is too small, because the user record holds order_ids, not the orders themselves. So the client has to send a second request. The second request cannot start until the first one has finished.
On a phone, 610 ms means most of a second of blank screen. The screen waits for a third request to turn the product ids into names. The three requests could not run at the same time, because each request needed ids from the one before it. The three requests also moved 6900 bytes so the screen could show 8 of the 99 fields that came back.
REST has a reasonable fix: GET /screens/profile, an endpoint that returns exactly the eight fields the profile screen shows. So the profile call takes one trip, 600 bytes and 250 ms. But the order screen and the settings screen each need their own endpoint, so every new screen means a deploy. A ?fields= parameter on the old endpoint does the same job with less setup, but the server still decides which fields exist.
Speed was never the point, because the purpose-built endpoint was as fast as anything that comes after it. The real question is who decides the response shape. In REST, the server decides the shape, one endpoint at a time. The next two chapters give the other two answers.

The contract compiles the call

In gRPC, a file checked into the repository beside the code decides the response shape. That file, orders.proto, names one service, one method, and the message the server returns. The number after each field in the message is what gets sent over the network. So once a field has the number 2, that field must keep the number 2 forever.
In gRPC, a mismatch between client and server is now a compile error. The compiler writes the client and server stubs from one file, so nobody types them by hand and they cannot get out of sync. Rename product_name in the file, and both projects stop compiling. A REST client would have found the same mistake in production, when a user reported a 400 error.
gRPC is fast for two reasons, and both matter. First, gRPC encodes messages with protobuf, a binary format that writes the field number 2 where JSON writes the text total_cents. So the same three fields take 22 bytes instead of 61. Second, HTTP/2 sends the four calls over one connection instead of four separate connections, so no call waits in a queue behind another call.
The gRPC contract file covers more than the fields. It also decides how many messages each call sends. A REST endpoint gives you only one of the four call shapes, called unary: one message out and one back. The other three keep the stream open: one out and many back, many out and one back, or both directions at once. With REST, you build those three yourself.
gRPC has a cost in the browser, because the browser cannot make a gRPC call on its own. The browser's fetch API cannot set the HTTP/2 frames that gRPC needs. So a grpc-web proxy between the browser and the server has to translate each call. The browser's network tab shows 22 bytes of binary, not a body you can read. This cost is why gRPC is used inside a system.
No single choice of who decides the shape fits every caller, so a real system runs REST, GraphQL and gRPC together. REST runs at the public edge, because any client can call a REST endpoint and a CDN can cache REST responses. GraphQL runs where many screens each want their own response shape, and you would rather not deploy again for each screen. gRPC runs between your own services, where both ends are your code and the contract compiles.

Chapter 1 · step 1 of 6

A profile screen needs its data in one exact shape. The screen has four rows: the name with its avatar, then the last three orders, each with a product name and a total. But the server that answers the request has never seen this screen. Every problem in this concept comes from the server not knowing that shape.

1 of 6 Use ← → or swipe See the concept: all 3 chapters in it

How well did you know this?

AI:

Saved in this browser - sign in to keep your review list.

How should your speech become text?

Listening… your words appear above as you speak - tap Stop when you're done.

Recording · cr - tap Stop & transcribe when you're done.

Transcribing with AI…

Voice:

Keep going - a few more words and AI can grade it.

Interview lens How interviewers actually use this question

Likely follow-ups

How would a browser app call your gRPC service? Browsers can't control raw HTTP/2 frames, so it goes through gRPC-Web and a proxy like Envoy. That supports unary and server streaming, not bidi.
How do you load balance gRPC traffic, and why does a plain L4 load balancer fall short? HTTP/2 keeps one long-lived connection carrying many calls, so an L4 balancer pins them all to one backend. Use an L7 proxy or client-side balancing.
How do you change a .proto message without breaking clients that are already deployed? Never reuse or renumber field numbers, reserve removed ones, add new fields instead of changing types, and rely on old code skipping unknown fields.
Why can't a CDN cache gRPC responses the way it caches REST GETs? gRPC sends calls as HTTP POST to a method path, so URL-keyed caching, Cache-Control and ETags don't apply. Cache in the service or the client.
Your services talk gRPC internally, but partners need a public REST API. How do you serve both? An edge gateway or JSON transcoding, such as grpc-gateway, maps REST routes to gRPC methods, so one proto contract backs both.

What you can say

The main difference is the contract and the wire format, since gRPC sends binary messages defined by a strict Protocol Buffers contract, while REST sends readable JSON to resources using HTTP verbs.
gRPC runs on HTTP/2, so it can stream in both directions, and binary messages are cheaper to parse than text, which gives it lower latency.
The .proto file also gives you generated, typed clients, which is a big reason it fits service-to-service calls in a microservices setup.
REST works over HTTP/1.1 or HTTP/2, any browser or tool like curl can read it, and GET responses can use normal HTTP caching.
The downside of gRPC is that it needs gRPC-Web to run in a browser, caching is limited, and the learning curve is steeper.
So I'd use gRPC for internal service calls where speed and typed clients matter, and REST for public or browser-facing APIs, where caching and plain JSON matter more than raw speed.

Weak answers to avoid

Says gRPC is just a faster REST Speed is one row of the comparison. The contract, streaming, browser support and caching all differ, so say when each one fits instead of naming a winner.
Recites the table with no recommendation The interviewer wants a choice. Say gRPC for internal service calls and REST for public and browser-facing APIs, and give the reason for each.
Ties REST to HTTP/1.1 only REST runs fine over HTTP/2 too. The real gap is gRPC's binary protobuf contract and its streaming, not the HTTP version.
Pitches gRPC for a browser front end as is Browsers can't call gRPC directly. Mention that it needs gRPC-Web, usually behind a proxy, before recommending it for a web client.

Interview lens

Likely follow-ups, what you can say, and the weak answers to avoid.

Want a quick review of the fundamentals? See the API Design cheatsheet.

← Back to all API Design questions

Pro · $10/mo

74 of 92 API Design answers are in Pro.

Full answers, code samples, and AI explanations that go simpler or deeper. Cancel anytime.

Full answers + code
AI explanations, simpler or deeper
1,000 AI credits / month
Cancel anytime

Get Pro → See plans & pricing →