RPC is the older idea by decades: call a named procedure on a remote machine as if it were local. You
invoke an operation with parameters and get a result. POST /createInvoice. The mental model is
actions.
REST inverts that. The mental model is resources with addresses, and a small fixed set of verbs that
mean the same thing everywhere. POST /invoices. The uniformity is what makes REST governable at
scale — a developer who has used one of your resource collections can predict the next one.
The industry told itself a story where REST replaced RPC and that was progress. The story is wrong. API styles are not a linear march; they are a toolbox of enduring models, each suited to different problems. RPC shaped the early web API era through XML-RPC and JSON-RPC, receded during the REST years, and came back at full strength as gRPC, which is CORBA’s direct intellectual descendant done properly.
Practically: use resource-oriented REST for public, broadly consumed, long-lived interfaces where predictability and cacheability matter. Reach for RPC-shaped operations when the thing you are exposing genuinely is an action rather than a resource — and accept that most real APIs have a few of those and are better for admitting it than for contorting them into fake resources.
