RPC — Remote Procedure Call — is one of the oldest and most persistent ideas in the history of distributed computing, and it runs through the entire story of APIs like a recurring theme that keeps coming back in new clothes. The RPC model is simple and intuitive: call a procedure (a function, a method) on a remote machine as if it were local. You invoke a named operation with some parameters, and you get a result back. This is a fundamentally different mental model from REST’s resource orientation — RPC thinks in terms of actions and procedures, while REST thinks in terms of resources and representations. RPC predates the web APIs we know today by decades, it shaped the early web API era, it was overshadowed by REST, and it has come roaring back through gRPC. When I trace the 50-year history of influences on APIs, RPC is one of the deepest roots, and understanding it is essential to understanding both where APIs came from and where they keep returning.
The lineage of RPC is long and foundational, stretching back through the whole history of distributed computing. In my timeline of what has influenced APIs over the last 50 years, RPC appears repeatedly: ONC RPC in the 1990s, the broader RPC tradition from the CORBA and DCE era, and then the web-era incarnations. XML-RPC arrived in 1998 as one of the very first web APIs — a genuinely simple way to make remote procedure calls over HTTP using XML, which predates and influenced SOAP. JSON-RPC followed, applying the same RPC model with JSON instead of XML. These web-era RPC protocols were the bridge between the older distributed-computing RPC tradition and the modern web API world. RPC wasn’t invented for the web; it was inherited by the web from decades of distributed-systems work, and the early web APIs were substantially RPC in character before REST became dominant.
The RPC-versus-REST tension is one of the defining architectural debates in API history, and I’ve never been dogmatic about it. The REST movement, building on Roy Fielding’s work, positioned itself against RPC — arguing that resource orientation, using HTTP as designed, was superior to RPC’s action orientation. And for public web APIs, REST largely won the argument, becoming the dominant style. But RPC never went away, because the RPC model is genuinely well-suited to certain problems. I’ve consistently argued, in posts like “API is not just REST,” that RPC is a legitimate, viable approach despite the criticism from REST purists — and I’ve pointed out that hugely successful APIs from Flickr, Amazon, Slack, and others have used RPC-style designs and done just fine. The RPC-versus-REST debate generated a lot of heat and a lot of dogma, but the honest historical assessment is that both models have their place, and the insistence that RPC was simply wrong was always more ideology than engineering.
The persistence of RPC is the most instructive part of its history, because it keeps proving it can’t be dismissed. Even after REST became dominant for public APIs, RPC persisted in the places it fit well — internal systems, performance-critical service-to-service communication, action-oriented operations that don’t map cleanly to resources. I’ve always included RPC in my diverse API toolbox, alongside REST, hypermedia, GraphQL, and the rest, because a mature practitioner reaches for the right model for the problem rather than forcing everything into one style. RPC defined as a protocol using XML or JSON over HTTP, distinguished from resource-based approaches, remained a real and useful option throughout the REST era. The fact that RPC never died, despite REST’s dominance, tells you that the RPC model captures something genuinely useful about how systems communicate — the action-oriented, procedure-calling mental model that’s simply more natural for certain kinds of operations.
The gRPC resurgence is RPC’s triumphant return, and it’s the clearest proof that the RPC idea was never obsolete. gRPC — Google’s modern RPC framework, built on Protocol Buffers and HTTP/2 — brought RPC roaring back into relevance, and it succeeded precisely where the older RPC traditions like CORBA had failed. gRPC is the direct intellectual descendant of the entire RPC lineage, executed with modern tooling, strong typing, and excellent performance. When I started learning gRPC from Google in 2017, what struck me was that the RPC instinct, done well, was genuinely valuable for internal, high-performance, service-to-service communication. gRPC proved that RPC wasn’t a dead end that REST had superseded, but a parallel tradition that had its own enduring strengths and its own appropriate domain. The RPC model that the early web APIs inherited, that REST seemed to overshadow, came back as one of the most important API technologies of the microservices era.
The historical lesson of RPC, the one I’d want anyone to take from it, is that API styles aren’t a linear progression where each new approach makes the previous ones obsolete — they’re a toolbox of enduring models, each suited to different problems, that keep recurring across the decades. RPC is the oldest of the web API styles, predating REST, and it has outlasted every prediction of its demise. It shaped the early web API era through XML-RPC and JSON-RPC, persisted through the REST-dominant years in the places it fit, and returned to prominence through gRPC. The recurring pattern in API history — that the action-oriented RPC model keeps coming back because it captures something genuinely useful — is a corrective to the tendency to think of API evolution as a march of progress in which the latest style is simply the best. RPC is the proof that the foundational models endure: the procedure call, the action-oriented invocation of remote operations, is one of the deepest and most persistent ideas in distributed computing, and it has been part of the API story from before the beginning and remains part of it today. When you understand RPC’s long history — its ancient roots, its early web incarnations, its eclipse by REST, and its resurrection through gRPC — you understand that the history of APIs isn’t a story of one style replacing another, but of a set of enduring models that each keep finding their moment. RPC’s moment keeps coming back, which is exactly why it deserves to be understood as one of the foundational chapters in the whole history of APIs.
References
- API Technology: SOAP
- History Of APIs: Birth Through Social
- API Design Industry Guide: gRPC, Open Source RPC Framework
- REST, Linked Data, Hypermedia, GraphQL, And gRPC
- What You Can Expect As A Client From SOAP To gRPC
- API Is Not Just REST
- What Else Has Influenced APIs Over The Last 50 Years
- Expanding My API Toolbox For The Next Decade
