RPC-style API
An API organized around commands like /cancelOrder or chat.postMessage instead of resource URLs like /orders/42.
See it
What it is
An RPC-style API names the operation itself: POST /sendEmail, /orders/42:cancel, or Slack's chat.postMessage. The request is a command with arguments and the response is its result. REST starts from a resource and uses HTTP methods to act on it; RPC starts from the action the caller wants performed.
Reach for it when the domain operation is richer than a plain create, read, update, or delete. Cancel an order, approve an expense, rotate a key, and retry a payout all have rules and side effects worth naming. A clear command endpoint is more honest than hiding the operation inside PATCH /orders/42 with a magic status value.
The gotcha is turning every small edit into a new verb and ending up with hundreds of inconsistent commands. Keep ordinary record work as resource endpoints, use RPC-style actions for real domain commands, and document whether each command is safe to retry. Most commands use POST, so HTTP caches and idempotency semantics will not rescue a vague contract.
Ask AI for it
Design these business operations as RPC-style HTTP endpoints. Use POST /orders/{id}:cancel and POST /orders/{id}:retry-payment for commands, keep ordinary reads at GET /orders/{id}, and describe every operation in an OpenAPI 3.1 document. Give each command a typed JSON request, a typed result, RFC 9457 problem details for failures, authorization rules, and an Idempotency-Key requirement wherever retrying could repeat a side effect.