# RPC vs REST

> RPC models an API as callable operations; REST models it around resources and standard HTTP semantics. Choose RPC when explicit service contracts or streaming matter, often using gRPC; choose REST when broad client compatibility, resource-oriented APIs, and HTTP caching are priorities.

Source: https://sysround.com/compare/rpc-vs-rest
Updated: 2026-11-05


## Side by side

| | RPC | REST |
|---|---|---|
| API model | Operations: ReserveInventory(request) | Resources: POST /reservations |
| Transport and encoding | Implementation-dependent; gRPC commonly uses HTTP/2 and Protobuf | Typically HTTP; JSON is common, not required |
| Contracts and clients | Schema-driven tooling is common with gRPC | OpenAPI can provide schemas and generated clients |
| Caching | Usually application-managed | GET supports standard HTTP cache controls |
| Streaming | gRPC supports client, server, and bidirectional streams | HTTP streaming or SSE can complement resource APIs |
| Client compatibility | Depends on runtime; browser gRPC needs adaptation | Broad browser, CLI, and third-party support |
| Retry safety | Defined per operation; not implied by RPC | HTTP methods express safety and idempotency semantics |
| Performance | Binary encoding can reduce overhead; measure it | Depends on encoding, caching, connection reuse, and workload |

## The differences that matter

The main difference is the interface model, not the wire format. RPC exposes operations such as TransferFunds or GetQuote. REST exposes resources such as transfers and quotes, with HTTP methods carrying standard semantics. RPC is a broad category, while gRPC is one implementation; REST does not require JSON.

Contracts affect how teams deploy changes. gRPC commonly generates clients and servers from Protobuf definitions, making types and service methods explicit. REST can offer comparable tooling through OpenAPI. Neither approach eliminates compatibility work: old clients must still tolerate changes, and Protobuf field numbers must not be reused.

REST makes standard HTTP caching easier to use for suitable reads. A GET response can carry Cache-Control and validators such as ETag, allowing browsers, proxies, or CDNs to reuse it when permitted. RPC responses can also be cached, but cache keys, freshness, and invalidation usually need application-specific handling. Personalized responses require careful cache isolation either way.

Transport capabilities and operational support can change the choice. gRPC offers built-in streaming and deadlines, but browsers typically need gRPC-Web or a gateway, and proxies must support the chosen transport. REST works naturally with common HTTP tooling and can use SSE for server-to-client updates. Neither approach makes remote calls reliable: timeouts, bounded retries, authorization, and duplicate side effects still need explicit design.

## Choose RPC when

- Internal services need explicit operation contracts and generated clients across several supported languages.
- Client, server, or bidirectional streaming is a core requirement, and gRPC fits the clients and infrastructure.
- Measured serialization or network overhead justifies a compact binary encoding such as Protobuf.
- Domain operations are clearer as commands, such as EvaluateRisk or RebalancePartitions, than as resource manipulation.

## Choose REST when

- The API serves browsers, external developers, or clients that benefit from ordinary HTTP tooling.
- The domain maps naturally to resources, collections, filtering, and pagination.
- Cacheable reads should use browser, proxy, or CDN caching with standard HTTP controls.
- You want a public HTTP API without requiring clients to adopt a particular RPC runtime.

## Worked example: REST at the payment edge, RPC between services

Suppose a payment API must support browser checkout and partner integrations, with a target of 250 ms for accepting a payment request. Expose POST /payments with an idempotency key, then let clients retrieve status through GET /payments/{id}. Internally, the payment service can call a risk service through gRPC with a generated schema and a deadline within the overall request budget. A timeout must not trigger an unbounded retry or create a second payment. Store the idempotency key and result durably, and define what happens if risk evaluation is unavailable. The split is justified by client compatibility and internal contracts, not an assumed gRPC speedup.

## In the interview

- Start with the callers and interaction pattern: browsers or backend services, request-response or streaming, public or controlled clients. Then name the implementation, such as REST over HTTP with JSON or gRPC with Protobuf.
- Separate API style from performance claims. Explain whether bytes, serialization CPU, connection setup, or downstream work dominates, and propose measuring representative payloads before claiming one option is faster.
- Describe one failure path. If a charge request times out after committing, neither RPC nor REST tells the caller whether it succeeded; use an idempotency key and a way to retrieve the result.
- Expect probes about evolution and operations: backward-compatible schema changes, old client support, deadline propagation, retry budgets, proxy compatibility, and observability. A REST edge with internal gRPC is valid, but the gateway adds translation and operational work.

## Common mistakes

- Treating RPC as synonymous with gRPC, or REST as synonymous with JSON over HTTP.
- Claiming RPC is always faster without considering payloads, caching, connection reuse, and downstream latency.
- Assuming REST makes every request retry-safe, or that an RPC deadline guarantees the server stopped processing.
- Choosing only by public versus internal placement instead of checking client support, interaction patterns, and operational constraints.

## Interview questions where it comes up

- [Design a payment system](https://sysround.com/questions/design-payment-system): Public payment endpoints and internal service calls require explicit contracts, retry-safe operations, and handling of uncertain outcomes regardless of API style.
- [Design a ride hailing app like Uber](https://sysround.com/questions/design-uber): Mobile-facing APIs, internal matching calls, and high-frequency location streams create different client and transport requirements.
- [Design a weather app](https://sysround.com/questions/design-weather-app): Resource-oriented weather reads can benefit from HTTP caching, while freshness and location-based cache keys determine whether reuse is correct.
- [Design a control plane for a distributed database](https://sysround.com/questions/design-database-control-plane): Fleet operations can use resource APIs or explicit RPC commands, but either design must expose durable operation status rather than depend on long-running calls.

## FAQ

### Is gRPC the same as RPC?

No. RPC is an API model in which clients invoke remote operations; gRPC is a framework that implements that model. Other RPC systems can use different transports, encodings, and tooling.

### Is RPC faster than REST?

Not inherently. gRPC with Protobuf can reduce serialization and payload overhead compared with a JSON API, but actual latency depends on the workload, connection behavior, caching, and downstream services. A cacheable REST read can avoid an origin call entirely, so compare complete request paths rather than labels.

### When should I use RPC instead of REST?

Use RPC when operation-oriented contracts, generated clients, or supported streaming patterns are important to your callers. Use REST when resource semantics, broad HTTP compatibility, and standard caching are stronger requirements. You can use both at different boundaries, provided the extra gateway and contract maintenance are worthwhile.

## Related concepts

- [REST API design](https://sysround.com/concepts/rest-api-design)
- [Serialization formats](https://sysround.com/concepts/serialization-formats)
- [API versioning](https://sysround.com/concepts/api-versioning)
- [Idempotency and idempotency keys](https://sysround.com/concepts/idempotency)
- [API gateway](https://sysround.com/concepts/api-gateway)


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.