When designing web APIs and web protocols, various styles cater to different use cases. Two such technologies are RPC and REST. Since their inception, these approaches to web-based communications have transformed how services function.

However, they go about this in different ways. Read on to learn more about RPC and REST and why each has become integral to today’s cloud-based computing environments.

What Is RPC?

Remote Procedure Call (RPC) is a unique approach to computing since it’s geared towards running remote workloads as if they’re initiated locally. RPC allows users to tap into services running within external networks — those services found within programs on other machines. Because of this, RPC can call processes via remote systems. It’s a method that allows two services to communicate.

This is enabled via the client-server model, in which the client program requests a service from the provider program (the “server”). Users can perform multiple procedural calls simultaneously thanks to multi-threading, even though these calls are synchronous. RPC also relies on an intermediary, a communicative link called an interface definition language (IDL). IDLs are essential for powering this RPC communication between machines running different operating systems or those using different languages.

RPC Examples

RPC has been a foundational technology for several successors over the years. One such variant is Google Remote Procedure Call (gRPC), an open-source solution launched in 2015, which arrived nearly 35 years after RPC’s conception. Google developed gRPC to patch RPC’s weaknesses. New features have included interoperability, HTTP/2 support, and Protocol Buffers support. Additionally, another alternative called distributed remote procedure call (DRPC) recently arrived as a lightweight option.

Another example of a service using RPC in practice is Microsoft Remote Procedure Call (RPC). The technology can help develop distributed client-server applications that use the Windows operating system. This RPC service is primarily designed for C/C++ programmers, helping take over some of the plumbing requirements from building out networks.

What Is REST?

Representational State Transfer (REST) is comparatively newer than RPC, having debuted in 2000. As an alternative to predecessors like SOAP, the REST architecture has long been the go-to choice for API developers across the microservices industry. It follows a structured approach and necessitates that developers clearly organize their resources using universal resource identifiers (URIs).

REST APIs follow the conventional CRUD philosophy, meaning that requests interact with resources via GET, POST, PUT, or DELETE operations. This is how REST APIs interact with databases and external services. Meanwhile, RPC-based APIs are largely limited to GET and POST.

Like RPC, REST leverages the client-server model. A RESTful service does not share its own resources; it only requests them or certain service functions. REST can work fairly seamlessly with different hardware, while RPC doesn’t offer as seamless hardware architecture flexibility.

Overall, REST brings numerous advantages to the table. The architecture is scalable, performant, portable, reliable, and relatively simple when used across a variety of tech stacks.

REST Examples

There are many examples of REST APIs in use today. For instance, Paypal’s REST API uses common HTTP methods and returns data in a JSON format, styles that have become a staple of RESTful API-based services. Using the API, developers can integrate features like payments, partner referrals, invoicing, and other Paypal services into third-party applications.

Another example of a REST API is Twilio. The Twilio REST APIs are the backbone of the Twilio platform, which enables developers to integrate all sorts of communication features, such as bulk SMS, voice, or chat, into their applications.

Understanding the Differences

The most fundamental difference between RPC and REST is that RPC was designed for actions, while REST is resource-centric. RPC executes procedures and commands with ease. Alternatively, REST is ideal for domain modeling and handling large quantities of data.

Next, let’s look at communication protocols. RPC is an older approach to API design, and thus relies on UDP or TCP to work properly. Accordingly, RPC can work using either connection-oriented or connectionless protocols. Developers can squeeze more performance from their RPC implementations by opting for UDP over TCP. UDP and TCP are transport-layer protocols because they’re designed within web frameworks.

Meanwhile, REST uses HTTP to communicate over the network. HTTP is considered an application layer protocol — not a transport layer protocol — and thus relies on user interactions to kick off-network activity. This layer sets the rules for data transmission.

How about functional differences within the client-server model? Once a call is made in RPC, the calling environment is suspended while the process is handed over to the server and then executed. Once that procedure is finished, the results are shipped back to the client. This is the query-response loop. RPC, therefore, excels in applications where control alternates between both parties. Execution in these implementations occurs synchronously.

Interactions are also defined differently between each approach. RPC relies on contractual negotiations; in other words, the client-server relationship directly influences how communication occurs. While contracts aren’t absent with REST, the arrangement is notably different. REST contracts are linked to hostnames, paths, HTTP methods, headers, request bodies, response bodies, and more. Additionally, RESTful interactions are defined via standardized terms.

These custom contracts make RPC ideal for IoT applications — especially low-powered ones — where REST might otherwise struggle due to resource consumption. Conversely, REST truly excels in hypermedia-dependent scenarios. It can group many different resources together and serve them in the appropriate format to users.

Each handles abstraction a little differently. While RPC hides the network communication processes from the user, REST uses resources to abstract information.

RPC vs. REST

RPC and REST have evolved considerably since their debut, and while each is useful, they’re functionally unique in significant ways. Each has its own use cases. While those use cases are critical to certain companies, it’s also good to note that both RPC and REST may be used together. Though it’s not advisable to combine styles in one API, you can implement both RPC and REST APIs side by side to achieve software robustness.

What’s old is also new again, thanks to emerging developments with gRPC and DRPC. While the original RPC has shown its age, both technologies are actively being used and iterated upon by the development community. We struggle to choose a true winner here — and truthfully, there isn’t one. Both approaches are quite powerful when used appropriately.