Start with use cases, not ideology
The right API style is the one that fits your actual use cases. REST fits resource-centric CRUD. GraphQL fits client-driven views and complex data graphs. RPC fits command-heavy workflows.
If you start from a trend instead of your constraints, you risk building a system that is hard to maintain or scale.
REST: predictable and ecosystem-friendly
REST aligns with HTTP, which means caching, logging, and debugging are easier. Most infrastructure understands REST semantics by default.
The trade-off is flexibility. If clients need custom shapes of data, REST often requires additional endpoints or query parameters.
GraphQL: flexible but operationally heavier
GraphQL allows clients to request exactly what they need, which can reduce bandwidth and simplify client-side logic.
But that flexibility comes with cost: resolvers, schema governance, potential performance pitfalls, and more complex caching.
RPC: action-first clarity
RPC is natural when your API is primarily about commands: `RunReport`, `SyncDevices`, `TriggerWorkflow`. It avoids forcing everything into resource semantics.
RPC loses some HTTP-native benefits. You must define your own conventions for caching, errors, and tooling.
Performance and caching trade-offs
REST benefits from HTTP caching. GraphQL and RPC often require custom caching strategies because requests are more dynamic.
If read performance is critical, REST is often the easiest to optimize. If bandwidth is the bottleneck, GraphQL may help.
Error handling and observability
REST uses status codes. GraphQL and RPC often embed errors in the response body. That difference matters for monitoring and alerting.
If your team relies on status-based monitoring, REST is simpler. If you use GraphQL/RPC, build explicit error metrics.
When a hybrid makes sense
Many systems use a hybrid: REST for standard resources, RPC for complex actions, and GraphQL for aggregation. This is valid if boundaries are clear.
The mistake is mixing styles without rules. Define where each style is allowed and document it.
A practical decision guide
Choose REST for simplicity, caching, and broad compatibility. Choose GraphQL when clients need highly customized data shapes. Choose RPC for workflows that do not map well to resources.
Start simple. You can always add a second style later if real constraints demand it.