REST vs RPC: How to Choose an API Style

REST and RPC are both ways to expose backend behavior over a network. The best choice depends less on fashion and more on how your domain is shaped.

REST thinks in resources

REST models the system as resources addressed by URLs. HTTP methods describe the operation.

GET /orders/123
POST /orders
PATCH /orders/123
DELETE /orders/123

This style works well when clients mostly create, read, update, and delete domain objects. It also aligns naturally with HTTP caching, status codes, and browser tooling.

RPC thinks in actions

RPC models the API as callable procedures or commands.

POST /calculateShippingQuote
POST /approveInvoice
POST /runFraudCheck

This style works well when the domain is action-heavy and the operation does not map cleanly to a single resource.

Practical tradeoffs

REST usually gives teams more predictable URL structures and better compatibility with HTTP infrastructure. RPC can be simpler when the product is mostly commands, workflows, or computation.

The worst API style is usually a confused hybrid: resource URLs that hide complex verbs, or RPC methods that duplicate every CRUD operation without a clear naming system.

How to choose

Choose REST when the domain has stable resources and standard lifecycle operations. Choose RPC when the domain is command-oriented, workflow-heavy, or closer to a service method than a resource representation.

Many production systems use both. Public APIs often lean REST. Internal service-to-service APIs may use RPC, gRPC, or message-based commands.