RPC vs REST

Internship at OpenGenus

Get FREE domain for 1st year and build your brand new site

In this article, we have covered the differences between REST and RPC. REST stands for Representational State Transfer and RPC stands for Remote Procedural Call.

Table of content:

  1. Differences between RPC and REST
  2. REST
  3. RPC

We will get started now.

1. Differences between RPC and REST

  1. RPC is action-oriented. In contrast, REST is resource-oriented.

  2. REST utilizes HTTP methods GET, POST, PUT, PATCH, and DELETE to perform CRUD operations. However, RPC only supports GET and POST requests.

  3. REST supports hypermedia which are hyperlinks included in the response to provide the client with links to other related resources whereas RPC does not.

  4. RPC implementations require payloads of certain data types such as XML for XML-RPC. In contrast, REST allows the client to specify Content-types or accept headers.

The two design architectures are widely used in Web services to build APIs. An API is an acronym for Application Programming Interface. It is a set of protocols that allows two systems to communicate to share resources and services.
The client sends a request to the server that sends back a response with data in JSON or XML format.
server
There are different types of APIs depending on the transport protocol used. However, the most common type of API is the HTTP API that uses HTTP(Hypertext Transfer Protocol) as the transport protocol between the client and server.

2. REST

The Representational State Transfer (REST) style is an abstraction of the architectural elements within a distributed hypermedia system. - Roy Thomas Fielding.

A REST API focuses on providing clients with resources from the server. The endpoints include the name of the resource being requested. The name of the resources should be nouns such as api/products and not verbs such as api/getProducts. Each resource usually has two URLs, one for a single resource entity or instance and one for a collection of resources.

REST APIs abide by the following design constraints:

  1. Statelessness. This implies that a request to a server needs to have all the necessary information to process it as servers do not store client request data.
  2. Client-Server. This means that the client and server should be two separate and independent entities. This greatly improves the system's scalability.
  3. Cacheable. This states that responses clearly state whether or not they are cacheable to prevent future irrelevant requests to the server as the data is already cached on the client-side. This improves the performance and scalability of the system as the request overhead is reduced.
  4. Layered System. The API design should ensure that the client and server don't know whether or not they are communicating directly with each other, or there are other layers of intermediaries between them. This is useful for scalability as well as security.
  5. Uniform Interface ensures that the data is transferred in a standardized form.
  6. Code on demand is an optional constraint and it enables the server to send code to the client to extend its functionality.

A REST API endpoint is a resource URL that utilizes HTTP verbs to perform CRUD (Create Read Write Delete) operations on the resource.

These HTTP verbs include GET, POST, PATCH, PUT and DELETE. These HTTP methods perform the following operations:

  • GET: retrieves data matching the resource URL
  • POST: sends data to the server to create a new entry
  • PATCH: makes a partial update to an existing resource
  • PUT: updates the entire existing resource
  • DELETE: deletes the resource specified by the resource URL

A common terminology out there is a RESTful web service that uses REST APIs to communicate.

Example of REST API

Let's take an example of how to create a REST API using the fakeStoreAPI.

  1. To retrieve all the products in the store:
Method: GET
Endpoint: https://fakestoreapi.com/products
  1. To retrieve a single product resource with id 12
Method: GET
ENDPOINT: https://fakestoreapi.com/products/12
  1. To add a new product resource
Method: POST
ENDPOINT: https://fakestoreapi.com/products
Data:  {} //Data in form of JSON
  1. To update a product resource with id 10
Method: PUT
ENDPOINT: https://fakestoreapi.com/products/10
Data:  {} //Data in form of JSON
  1. To delete a resource with id 5:
Method: DELETE
ENDPOINT: https://fakestoreapi.com/products/5

3. RPC

In distributed systems, a remote procedural call is when a client program calls a function whose implementation is in a remote server.

How RPC works

client

  1. The client calls a stub that has the same signature as the function in the server.
  2. The stub encodes the function arguments in a message that is passed to the server through the network in a process called marshalling.
  3. The server decodes the message and calls the function passing it the given arguments. This process is called unmarshalling.
  4. The function returns the value which is then passed back to the client as a response.

In Web services, RPC-style APIs focus on actions. Each endpoint represents an action the client can perform on the server.

The action is a function that is called on the server. Like a normal function that receives parameters and returns a value that is sent as a response to the client.

For an RPC API that uses HTTP as the transport protocol, the method or function is places in the URL and the arguments are placed either in the query string or body.

An example of an RPC call:

GET /getMovie/12 HTTP/1.1
Host: api.moviedb.com
Content-Type: application/json
Python
/* Function definition */ 
def getMovie(id) {
  // ...
}

/* Function call */
getMovie(id)

RPC APIs support only GET and POST requests.

Example of RPC API

Let's take a look at the Slack Web API that is RPC-based.

In the Users API

  1. To retrieve all users in a particular Slack team:
Method: GET
Endpoint: https://slack.com/api/users.list
  1. To retrieve information about a user
Method: GET
ENDPOINT: https://slack.com/api/users.info
body: {"token": xxxx-xxxxxxxxx-xxxx, user: "W1234567890"}

In the Chat API
3. To send a message to a particular channel

Method: POST
ENDPOINT: https://slack.com/api/chat.postMessage
  1. Deletes a message from a chat
Method: DELETE
ENDPOINT: https://slack.com/api/chat.delete

In the Conversations API
5. Retrieves all channels in a Slack team:

Method: GET
ENDPOINT: https://slack.com/api/conversations.list

Advantages of REST APIs

  1. REST APIs are scalable as the client and server are decoupled making it easier to scale in the future.
  2. They are simple and standardized making them easy to use.
  3. Takes advantage of the already existing HTTP features.
  4. They have high performance due to their cache capabilities.

Disadvantages of REST APIs

  1. The payload of a REST API is quite big as you get back the entire resource even if you just needed one field of the resource.

Advantages of RPC APIs

  1. Lightweight payloads.
  2. High performance.
  3. They are easy to understand as the action is part of the URL.

Disadvantages of RPC APIs

  1. Since it is not standardized, it is difficult for the client to find all the operations possible on the resources unlike a REST API.

In conclusion, when deciding which architecture to use when building your API, it's important to know what both architectures offer to make an informed decision. This is because both shine in their ways and it's up to you to decide on what your system needs.

References