Choosing between RPC and REST is rarely about taste. It is usually about contract shape, client evolution, and the real cost of a network call.
In real design work, the chapter shows how latency targets, integration shape, error contracts, versioning, and backward compatibility should drive the choice more than the current preference for JSON or protobuf.
In interviews and engineering discussions, it helps talk about remote calls through partial failure handling, fallback, hedging, and circuit breaker policy rather than only through API syntax.
Practical value of this chapter
Design in practice
Select RPC or REST style based on domain latency targets and integration shape.
Decision quality
Define error contracts, versioning, and backward compatibility as first-class API concerns.
Interview articulation
Compare options by client simplicity, observability, and maintenance cost.
Failure framing
Plan partial-failure behavior with fallback, hedging, and circuit-breaker policy.
Source
Remote procedure call
RPC definition and key properties.
RPC, REST and gRPC are different approaches to remote calling. They solve one problem: transmit a request over the network and receive a result, but they differ in interface style, level of formalization and typical application scenarios.
Source
REST
Architectural style, main limitations and properties.
Visualization of how the approaches work
Choose an approach and see how the request, response, and contract are formed between the parties.
How remote calls work
Choose an approach to see how request and response are formed
Request and response
Key properties
- Procedure call abstraction
- Focus on methods rather than resources
- Commonly uses binary serialization
What to keep in mind
Source
gRPC basics
Services, proto-contracts and types of RPC calls.
What do they have in common?
- They work on a client-server model and transmit requests over the network.
- They use data serialization and a contract between client and server.
- Require descriptions of errors, timeouts and retries.
How are they different?
RPC
- Focus on calling the method as a local function.
- Convenient for internal services and binary protocols.
- Client and server are often more strongly coupled.
REST
- Focus on resources and HTTP methods.
- Stateless and cached well.
- Better for public APIs and integrations.
gRPC
- The contract is described in .proto and generates code.
- Supports streaming calls.
- Well suited for microservices.
When to choose what
- RPC is convenient for internal services where speed and compact contracts are important.
- REST is suitable for public APIs and integrations where caching and interoperability are important.
- gRPC is good for microservices when a strict contract and streaming are needed.
Related chapters
- HTTP protocol - how REST and gRPC-over-HTTP/2 work at the application layer and what protocol overhead they add.
- TCP protocol - transport foundations for reliable RPC/REST calls: handshake, retransmission, flow and congestion control.
- UDP protocol - a contrast transport model for latency-critical scenarios without built-in delivery guarantees.
- Inter-service communication patterns - system-level sync/async integration choices, retries, and backpressure strategies.
- Service Discovery - how clients discover healthy service endpoints under dynamic scaling and failover.
- API Gateway - protocol translation, auth, rate limiting, and a controlled entry point for clients.
- API Design Patterns (short summary) - contract patterns and API evolution techniques that reduce integration breakage.
- Why distributed systems and consistency matter - moves from protocol choice to distributed trade-offs across latency, availability, and consistency.