gRPC vs REST

The Quick Summary

REST and gRPC are both ways to call functions on a server. They differ in protocol, format, and ergonomics.

REST uses HTTP verbs and JSON. Resource-oriented. Browser-friendly. Self-documenting through OpenAPI.
gRPC uses HTTP/2 and Protocol Buffers. Function-oriented (call methods on services). Faster, with strong typing. Less browser-friendly.

REST

The pattern: model your API as resources (users, orders) and use HTTP verbs (GET, POST, PUT, DELETE) to operate on them.

GET /users/42
POST /users {"name": "Alice"}
PUT /users/42 {"name": "Alice Smith"}
DELETE /users/42

Body is usually JSON. URLs are paths. Status codes (200, 404, 500) indicate outcomes.

Pros: universal. Every language, every browser, every tool. Easy to debug (curl, browser dev tools). OpenAPI specs make documentation and codegen possible.
Cons: JSON is verbose. No strong typing across language boundaries. The mapping from "I want to do X" to "what HTTP verb and path?" is sometimes awkward.

gRPC

You define services and methods in a Protocol Buffer (.proto) file:

service UserService {
    rpc GetUser(GetUserRequest) returns (User);
    rpc CreateUser(CreateUserRequest) returns (User);
}

message User {
    int64 id = 1;
    string name = 2;
    string email = 3;
}

The .proto file is the contract. Both client and server generate code from it. The wire format is binary (Protocol Buffers), much smaller and faster to parse than JSON. Transport is HTTP/2.

Pros: fast. Strong typing across languages. Native streaming (client streaming, server streaming, bidirectional). Smaller payloads. Better tooling for service-to-service.
Cons: not browser-friendly directly (needs a gRPC-Web proxy). Debugging is harder (binary). Less universal tooling. Schema must be shared between client and server.

Comparison

When to Use REST

Public APIs. External consumers will use any language and many tools. JSON over HTTP is the lowest common denominator.
Browser-first apps. Direct browser access without a proxy.
Simple CRUD. The resource model fits naturally.
Quick prototyping. Less ceremony to start.

When to Use gRPC

Internal microservices. Performance matters; the schema discipline is a net positive.
Polyglot teams. Generated clients in many languages keep them in sync.
Streaming. Native client-streaming, server-streaming, and bidirectional streaming.
Mobile. Smaller payloads matter on cellular.
Service mesh integration. Many service meshes (Istio, Linkerd) integrate well with gRPC.

The GraphQL Aside

GraphQL is a third option. It's request-driven (client specifies exactly what data it wants), uses HTTP, JSON-based.

Use GraphQL when: clients have varied data needs and you want to avoid over-fetching/under-fetching. Common for mobile apps backing onto a complex schema.
Skip GraphQL when: simple CRUD, or you need fine control over query cost.

Other Considerations

Caching: REST is cache-friendly (HTTP caches, CDNs work natively). gRPC is harder to cache.
Rate limiting: easier to apply to REST. Per-method gRPC rate limits need additional infrastructure.
Versioning: REST often does it via URL prefix (/v1/, /v2/) or content type. gRPC versions through service names and proto files.
Error handling: REST uses HTTP status codes. gRPC has its own status codes plus rich error metadata.

The Hybrid Approach

Many companies use both. REST for public APIs and browsers. gRPC for internal service-to-service. A gateway translates between them at the edge. This gets you the universal accessibility of REST and the performance of gRPC where each shines.

The One Thing to Remember

REST is the universal default; gRPC is the specialist. For internal microservices where performance and type safety matter, gRPC wins. For public APIs and browser-first applications, REST is still the right call. They're not really competitors; they solve overlapping but distinct problems. Knowing both, and having a translation gateway between them, is the modern practice.