What’s the Difference Between RPC and REST? Posted inDesign Tyler Charboneau March 22, 2022 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 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.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.Understanding the DifferencesThe 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. RESTRPC 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.