0% found this document useful (0 votes)
3 views

aws.amazon.com-RPC vs REST - Difference Between API Architectures

Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views

aws.amazon.com-RPC vs REST - Difference Between API Architectures

Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

RPC vs REST - Difference Between API Architectures

aws.amazon.com/compare/the-difference-between-rpc-and-rest

What's the difference between RPC and REST?


Remote Procedure Call (RPC) and REST are two architectural styles in API design. APIs are mechanisms that enable two
software components to communicate with each other using a set of definitions and protocols. Software developers use
previously developed or third-party components to perform functions, so they don’t have to write everything from scratch. RPC
APIs allow developers to call remote functions in external servers as if they were local to their software. For example, you can
add chat functionality to your application by remotely calling messaging functions on another chat application. In contrast, REST
APIs allow you to perform specific data operations on a remote server. For example, your application could insert or modify
employee data on a remote server by using REST APIs.

Read about APIs »

Read about RESTful APIs »

What are the similarities between RPC and REST?


Remote Procedure Call (RPC) and REST are both ways to design APIs. APIs are essential in modern web design and other
distributed systems. They allow two separate, distributed applications or services to communicate without knowing the internals
of how the other one works. These two applications or services may have little to do with one another except for a small data
exchange.

APIs are also a common mechanism for the backend of a program (the logic component) to communicate with the frontend of a
program (the display component). When you design web pages and web applications with APIs instead of tightly coupled
integration, you ensure they can scale and change with less code rewriting.

Next, we discuss other similarities between RPC and REST APIs.

Abstraction
While network communications are the main aim of APIs, the lower-level communications themselves are abstracted away from
API developers. This allows developers to focus on function rather than technical implementation.

Communication
Both REST and RPC use HTTP as the underlying protocol. The most popular message formats in RPC and REST are JSON
and XML. JSON is favored due to its readability and flexibility.

Cross-language compatibility
Developers can implement a RESTful or RPC API in any language they choose. So long as the network communication element
of the API conforms with the RESTful or RPC interface standard, you can write the rest of the code in any programming
language.

Architecture principles: RPC vs. REST


In Remote Procedure Call (RPC), the client makes a remote function (also known as method or procedure) call on a server.
Typically, one or more data values are passed to the server during the call.

In contrast, the REST client requests the server to perform an action on a specific server resource. Actions are limited to create,
read, update, and delete (CRUD) only and are conveyed as HTTP verbs or HTTP methods.

RPC focuses on functions or actions, while REST focuses on resources or objects.

1/5
RPC principles
Next, we discuss some principles that RPC systems typically follow. However, these principles are not standardized like REST.

Remote invocation
An RPC call is made by a client to a function on the remote server as if it were called locally to the client.

Passing parameters
The client typically sends parameters to a server function, much the same as a local function.

Stubs
Function stubs exist on both the client and the server. On the client side, it makes the function call. On the server, it invokes the
actual function.

REST principles
REST principles are standardized. A REST API must follow these principles to be classified as RESTful.

Client-server
The client-server architecture of REST decouples clients and servers. It treats them each as independent systems.

Stateless
The server keeps no record of the state of the client between client requests.

Cacheable
The client or intermediary systems may cache server responses based on whether a client specifies that the response may be
cached.

Layered system
Intermediaries can exist between the client and the server. Both client and server have no knowledge of them and operate as if
they were directly connected.

Uniform interface
The client and server communicate via a standardized set of instructions and messaging formats with the REST API. Resources
are identified by their URL, and this URL is known as a REST API endpoint.

How they work: RPC vs. REST


In Remote Procedure Call (RPC), the client uses HTTP POST to call a specific function by name. Client-side developers must
know the function name and parameters in advance for RPC to work.

In REST, clients and servers use HTTP verbs like GET, POST, PATCH, PUT, DELETE, and OPTIONS to perform options.
Developers only need to know the server resource URLs and don't have to be concerned with individual function names.

The following table shows the type of code the client uses to perform similar actions in RPC and REST.

Action RPC REST Comment

2/5
Adding a POST /addProduct POST /products RPC uses POST on function,
new HTTP/1.1 HTTP/1.1 and REST uses POST on URL.
product to
a product HOST: HOST:
list api.example.com api.example.com

Content-Type: Content-Type:
application/json application/json

{"name": "T-Shirt", {"name": "T-


"price": "22.00", Shirt", "price":
"category": "22.00",
"Clothes"} "category":
"Clothes"}

Retrieving POST /getProduct GET RPC uses POST on function


a HTTP/1.1 /products/123 and passes parameter as JSON
product’s HTTP/1.1 object. REST uses GET on URL
details HOST: and passes parameter in URL.
api.example.com HOST:
api.example.com
Content-Type:
application/json

{"productID": "123”}

Updating POST PUT RPC uses POST on function


a /updateProductPrice /products/123 and passes parameter as JSON
product’s HTTP/1.1 HTTP/1.1 object. REST uses PUT on URL
price and passes parameter in URL
HOST: HOST: and as JSON object.
api.example.com api.example.com

Content-Type: Content-Type:
application/json application/json

{"productId": "123", {"price": "20.00"}


"newPrice": "20.00"}

Deleting a POST DELETE RPC uses POST on function


product /deleteProduct /products/123 and passes parameter as JSON
HTTP/1.1 HTTP/1.1 object. REST uses DELETE on
URL and passes parameter in
HOST: HOST: URL.
api.example.com api.example.com

Content-Type:
application/json

{"productId": "123""}

Key differences: vs. REST

3/5
Remote Procedure Call (RPC) and REST are both ways to design corresponding client and server system interfaces for
communication over the internet. However, the structure, implementation, and underlying principles differ. Systems designed
with REST are known as RESTful APIs, whereas systems designed with RPC are simply RPC APIs.

Next, we give some more differences.

Time of development
RPC was developed in the late 1970s and early 1980s, while REST was a term first coined by computer scientist Roy Fielding in
2000.

Operational format
A REST API has a standardized set of server operations because of HTTP methods, but RPC APIs don’t. Some RPC
implementations provide a framework for standardized operations.

Data passing format


REST can pass any data format and multiple formats, like JSON and XML, within the same API.

However, with RPC APIs, the data format is selected by the server and fixed during implementation. You can have specific
JSON RPC or XML RPC implementations, and the client has no flexibility.

State
In the context of APIs, stateless refers to a design principle where the server does not store any information about the client's
previous interactions. Each API request is treated independently, and the server does not rely on any stored client state to
process the request.

REST systems must always be stateless, but RPC systems can be stateful or stateless, depending on design.

When to use: RPC vs. REST


Remote Procedure Call (RPC) is typically used to call remote functions on a server that require an action result. You can use it
when you require complex calculations or want to trigger a remote procedure on the server, with the process hidden from the
client.

Here are actions where RPC is a good option:

Take a picture with a remote device’s camera


Use a machine learning algorithm on the server to identify fraud
Transfer money from one account to another on a remote banking system
Restart a server remotely

A REST API is typically used to perform create, read, update, and delete (CRUD) operations on a data object on a server. This
makes REST APIs a good fit for cases when server data and data structures need to be exposed uniformly.

Here are actions where a REST API is a good option:

Add a product to a database


Retrieve the contents of a music playlist
Update a person’s address
Delete a blog post

Why did REST replace RPC?


While REST web APIs are the norm today, Remote Procedure Call (RPC) hasn’t disappeared. A REST API is typically used in
applications as it is easier for developers to understand and implement. However, RPC still exists and is used when it suits the
use case better.

4/5
Modern implementations of RPC, such as gRPC, are now more popular. For some use cases, gRPC performs better than RPC
and REST. It allows streaming client-server communications rather than the request-and-respond data exchange pattern.

Summary of differences: RPC vs. REST

RPC REST

What is it? A system allows a remote A set of rules that defines structured data
client to call a procedure on exchange between a client and a server.
a server as if it were local.

Used for Performing actions on a Create, read, update, and delete (CRUD)
remote server. operations on remote objects.

Best fit When requiring complex When server data and data structures
calculations or triggering a need to be exposed uniformly.
remote process on the
server.

Statefulness Stateless or stateful. Stateless.

Data In a consistent structure In a structure determined independently


passing defined by the server and by the server. Multiple different formats
format enforced on the client. can be passed within the same API.

How can AWS support your API requirements?


Amazon Web Services (AWS) has a range of services and tools to help API designers build, run, and manage API-based
modern applications and services. For more information, read about building modern applications on AWS.

Here are examples of AWS services that can help you meet your API requirements:

Amazon API Gateway allows developers to create, publish, and manage APIs at scale. With API Gateway, you can build
REST APIs optimized for containerized microservice architectures and web applications.
Elastic Load Balancing (ELB) distributes network traffic to improve application scalability. It can route and load balance
gRPC traffic between microservices or between gRPC-enabled clients and services. This allows for seamless gRPC
traffic management in software architectures without changing any underlying infrastructure for customers’ clients or
services.
Amazon Virtual Private Cloud (Amazon VPC) Lattice is an application networking service that consistently connects,
monitors, and secures communications between your services. Scale compute and network resources automatically to
support high-bandwidth HTTP, HTTPS, and gRPC workloads.

5/5

You might also like