gRPC vs REST

REST has been the standard way for services to communicate since the early 2000s. gRPC is newer and designed to fix the performance and developer-experience gaps that REST leaves open. Understanding the difference helps you choose the right tool for each job.

How REST Works

REST sends data as human-readable text, almost always in JSON format, over HTTP/1.1. Every request is independent — the server holds no memory of previous requests.

REST Request:
─────────────────────────────────────────────
POST /users HTTP/1.1
Content-Type: application/json

{
  "name": "Alice",
  "age": 30,
  "city": "Berlin"
}
─────────────────────────────────────────────
Anyone can read this in a browser or terminal.

How gRPC Works

gRPC sends data as compact binary bytes over HTTP/2. The same user record looks nothing like readable text on the wire — it is a tightly packed sequence of numbers.

gRPC Request (on the wire — binary):
─────────────────────────────────────────────
0A 05 41 6C 69 63 65 10 1E 1A 06 42 65 72 6C 69 6E
─────────────────────────────────────────────
Machines decode this instantly. Humans cannot read it directly.

Side-by-Side Comparison

┌─────────────────────┬──────────────────────┬──────────────────────┐
│ Feature             │ REST                 │ gRPC                 │
├─────────────────────┼──────────────────────┼──────────────────────┤
│ Data Format         │ JSON (text)          │ Protobuf (binary)    │
│ Protocol            │ HTTP/1.1             │ HTTP/2               │
│ Speed               │ Moderate             │ Up to 10x faster     │
│ Payload Size        │ Larger               │ Up to 80% smaller    │
│ Contract            │ Optional (OpenAPI)   │ Required (.proto)    │
│ Code Generation     │ Manual or optional   │ Automatic            │
│ Streaming           │ Limited (WebSockets) │ Built-in             │
│ Browser Support     │ Full                 │ Needs gRPC-Web proxy │
│ Human Readable      │ Yes                  │ No (binary)          │
│ Error Handling      │ HTTP status codes    │Status codes + details│
└─────────────────────┴──────────────────────┴──────────────────────┘

Speed Difference Explained

Sending the word "Berlin" in JSON takes 8 bytes plus quotation marks and the key name. Protocol Buffers encode the same value using a field number and just 6 bytes of data — no key names at all.

JSON encoding of city field:
  "city": "Berlin"   →  16 bytes

Protobuf encoding of same field:
  1A 06 42 65 72 6C 69 6E  →  8 bytes

Savings: 50% for just one field.
Multiply across millions of requests per day → huge bandwidth savings.

The Contract Difference

REST has no mandatory contract. One developer might name a field user_name while another calls it userName. Both are valid JSON, but the mismatch breaks the client code silently.

gRPC enforces a strict contract. The proto file defines every field name and type. If the contract changes in a breaking way, the compiler refuses to generate code until both sides agree.

REST — no contract enforcement:
  Server sends: { "userName": "Alice" }
  Client reads: data.user_name  ← returns undefined, no error

gRPC — contract enforced at compile time:
  Proto says:  string user_name = 1;
  Client code: request.getUserName()  ← always matches, or won't compile

When to Choose REST

✔ Public APIs consumed by browser JavaScript
✔ Third-party integrations where you do not control the client
✔ Simple CRUD apps with low traffic
✔ Teams that need human-readable payloads for quick debugging

When to Choose gRPC

✔ Microservices talking to each other internally
✔ Mobile apps that need low latency and small data payloads
✔ Real-time streaming (live scores, stock tickers, chat)
✔ Polyglot systems (services in different languages)
✔ High-throughput systems handling millions of requests per second

Can You Use Both?

Yes. Many companies expose a REST API to the public and use gRPC internally between their own services. A reverse proxy like Envoy or a gRPC-Gateway can translate REST requests into gRPC calls automatically.

External World                 Internal System
─────────────────────────────────────────────────
Mobile Browser ──REST──► API Gateway ──gRPC──► OrderService
                                     ──gRPC──► InventoryService
                                     ──gRPC──► PaymentService

Summary

REST is flexible, readable, and universally supported. gRPC is fast, strict, and efficient. Choose REST for public-facing APIs and browser clients. Choose gRPC for internal service-to-service communication where speed and type safety matter most.