REST vs. RPC vs. GraphQL vs. Events

REST works well for resource-oriented public APIs and benefits from familiar HTTP semantics. RPC exposes operations such as ReserveInventory; it can express domain commands clearly and may use generated contracts. GraphQL lets clients request a shaped graph of data and can reduce over-fetching, but needs query-cost controls, authorization at field boundaries, and caching strategy.

Asynchronous event interfaces decouple producers from consumers in time. A producer publishes an event such as OrderPlaced; consumers process it independently. This improves isolation and absorbs bursts, but introduces eventual consistency, duplicate delivery, ordering questions, and operational complexity.

Choose an interface based on the interaction. A synchronous checkout command may need an immediate acceptance result, while sending an email can be asynchronous. Mixing styles is normal when each boundary has a clear purpose.

Interface selection
REST: Resources and HTTP semantics
Good general-purpose choice for web APIs.
RPC: Explicit operations
Useful for internal service calls and strongly typed contracts.
GraphQL: Client-selected response shape
Useful for complex client views; protect against expensive queries.
Events: Asynchronous facts or commands
Useful for decoupled processing, with delivery and consistency trade-offs.
Key Takeaways
  • No API style is best for every interaction.
  • Asynchronous messaging is not a free performance upgrade.
  • Authorization and observability must cross every interface.