REST vs RPC: Picking the Right Style
REST vs RPC: Architectural Intent
REST and RPC are not just different URL styles. They represent different ways of thinking about APIs. REST models the system as resources with state transitions, while RPC models it as remote function calls. The choice impacts evolvability, client coupling, and documentation strategy.
REST Characteristics
- Resource-oriented URLs (e.g.,
/users/123) - Standard HTTP verbs (GET, POST, PUT, DELETE)
- Stateless requests
- Cache-friendly semantics
REST works well when your domain naturally maps to entities and relationships. It is especially effective for public APIs and frontend-backend separation.
RPC Characteristics
- Action-oriented endpoints (e.g.,
/createUser) - Function-like semantics
- Tighter client-server coupling
RPC can be simpler internally, especially in microservices where strong typing and well-defined contracts matter more than resource modeling purity.
Production Insight
For public-facing APIs, REST usually offers better long-term flexibility. For internal services, RPC-style endpoints can be clearer and more efficient. The critical rule is consistency: mixing both without clear boundaries creates confusion and maintenance cost.