The world wide web has become too complex today. With hundreds and thousands of electronic media talking to each other, the process of communication has become too complex and heavy on computation for sure. Such scenarios call for something that can ease out the communication and keep the coding complexity to a minimum as well.  That something is the focus of this post and is termed as REST.

REST, or REpresentational State Transfer, is an architectural style and provides standards between the systems on the web. Popularly, RESTful systems use the REST style to communicate with each other. So in many places, you might see "RESTful" over the internet and it means the same thing. In this article, we dwell in more details about REST basics and will cover the following topics in this article.

• What is REST - Representational State Transfer?
• What are Clients and Resources?
• Guiding principles or constraints of REST
  • Uniform interface
  • Client-server separation
  • Stateless
  • Layered system
  • Cacheable
  • Code-on-demand

What is REST - Representational State Transfer?

REST (REpresentational State Transfer) was first presented in the year 2000 by Roy Fielding as an architectural style for distributed hypermedia systems. REST-compliant or RESTful systems, are "stateless" (discussed later in this article) and separate a client and a server. A web application developed using REST (RESTful web application) exposes the data or information about its resources which can be anything that the developer wants. This allows the client using this application to take action on the resources. For example, using information exposed to users, clients can create a new user.

As another example, suppose we have a pet store and the information related to all pets in the store is stored on the server. If we want information related to a pet (let's say pet with id=0) then we will access the appropriate URL of the pet store in the browser (Here the browser will be the client). An example URL can be "https://demoqa.com/BookStore/v1/Books".

The above interface looks as shown below:

All the methods (coloured buttons) shown in the above screenshot correspond to REST APIs that are executed with the click of a button. Please note that this is a demo website and therefore the APIs are so explicit on the screen. In general, all this is done in the back-end and the client is not shown any of this information. Coming back, when we click the "GET" button (/Books), we will get the response in JSON format that will show us the details of the particular book. This response is shown below:

Note: When we click on the "GET" button, in the browser we see the link changes to "https://demoqa.com/BookStore/v1/Books".

We will discuss all the methods shown above (in form of buttons) in our subsequent articles.

Representation of REST flow

Now let us depict the actual REST data transfer in the above example in the diagram below.

As the above diagram shows, the API works as a medium of communication between a database (that is a part of a server) and a client. When a client sends data through APIs, it goes to the database, do the appropriate operation (such as add, delete, modify etc.) and return the response data that contains response code, header files, cookie info etc.

We can summarise the REST characteristics and the working in the above diagram as follows:

• A client access data from the server passed by REST. This can either be through authorized access or without following any strict guideline.
• As we can see, the application developed using REST is an interactive application and mostly it uses web services. In this case, the web service follows RESTful guidelines and fulfils the constraints of REST that are discussed later in this article.
• A web service using REST provides web resources in textual format and allows them to be read and edited using a predefined set of operations.

REST is a way to access a web service and is often viewed as an alternative to SOAP (Simple Object Access Protocol).

In a RESTFul application, we have entities namely client and resource which are used commonly. Let us discuss them briefly next.

What are Clients and Resources?

A client can be a software or a person or a system using the APIs to access data from another application server. For example, a developer might access Facebook APIs to embed a live post in their own website. The developer program will call the Facebook API through a browser. So in this case, the browser acts as a client that is calling the Facebook APIs.

If we visualize this system using the REST diagram above, the client or browser will connect to Facebook-Server over REST API and then get the information required to render it on the screen.

As another example, suppose I have an application "myHealthApp". I want data on the Covid-19 pandemic from a city, Pune, for example. To achieve this, I will develop APIs or methods, such as, "Corona API" using which I can request the data from Pune Municipal Council (PMC). This is done using myHealthApp. This means using myHealthApp which acts as a client, I will make a request for data using Corona API (say getCoronaData method to be more specific) through the browser ( for example, https://myHealthApp/getCoronaData). This getCoronaData method will in turn connect to PMC servers and fetch the required data as a JSON response (or any other format). On the client side, I can take that data and perform various operations on it. This is the use of APIs.

What Is A Resource in REST?

Any smaller unit that can be transformed and addressed through a URL and HTTP method is considered a resource. This resource makes changes to the database. For one application, you may have a lot of resources with all of them assigned a particular task. For example, an online book store may have a resource as a table of the database. A resource in a REST architecture is anything that a client has access to and can modify or update.

In a way, you can say that a resource is any object for which we need information from API. So in the above example about Facebook, a resource can be a post, page, or user account. In the example of Corona API, resources are all the details on Corona like Corona data, pages on treatment, vaccination, etc.

Guiding principles or constraints of REST

For an API to be RESTful, it has to fulfil or adhere to the following guiding principles or constraints defined by REST.

Uniform interface

The uniform interface principle has the following parts that an API has to follow:

1. The request to the server needs to have a resource identifier.
2. The server returns the response and includes information such that the client can modify or edit the resource.
3. The request sent through the API contains the information that the server needs to execute the request. Each response returned by the server also contains all the information so that client understands the response.
4. Hypermedia as the engine of application state. The application means the web application that is running on the server. Hypermedia is the hyperlinks or simple links included in the response. So the server basically informs the client about the ways to change the application web.

Client-server separation

The interaction between the client and the server is independent and is only in the form of requests. The client initiates a request and the server sends the responses. The response is a reaction to the request. So all server does is wait to receive requests from the client. It never sends out information about the resources to the client on its own. For more details on client-server refer to our tutorial, Client-server Architecture.

Stateless

The word "stateless" means the server does not keep track of the user who uses the API. So when a new request comes in, the server will not know if the same user has sent a GET request in the past for the same resource. It doesn't remember the resources requested by the user earlier. For example, HTTP is a stateless protocol. HTTP server does not keep track of any state of information passed to and fro. Hence at any given time, a client can send a valid command, and the server will not relate or keep track of any previous similar commands.

Hence each request regardless of the other requests made by the user will contain all the data needed by the server to execute the request and send a response.

Layered system

A layered system provides a hierarchical structure between a client and a server. There can be a lot of intermediaries between the client and the server working along with REST API without the client's notice. Our clients think there is a direct connection to the server. We then take advantage of it to improve our architecture and bring down our distributed system complexity. These intermediate elements provide a security layer, load-balancing layer, and other functionality to the system. The only guideline is that the presence of these intermediate layers should not affect the request or response.

Note: The abstraction of layers does not let one layer be aware of the presence of another layer.

Cacheable

The server data received in the response contains information regarding whether the data is cacheable or not. If the data is cacheable, it will contain some kind of version number that makes caching possible. The client will know which version of the data it has got from the previous response. This way client can avoid requesting repeated data. Cacheable data (and therefore version number) also helps the client to know the expiration of version data and the requirement of a new request to fetch the latest data.

Code-on-demand

This particular constraint "Code on demand" is optional and without fulfilling it we can have a RESTful API.

The client can send a request to the server asking for the code and then the server will respond with some code in the form of a script or some other entity. For example, servers can extend the client functionality by downloading and executing pre-compiled code like an applet or a client-side script like JavaScript. So when we click on any video on Facebook, Facebook will run a precompiled or any third-party software to run that video.

Once an API fulfils the above constraints we discussed, we can say it is a RESTful API.

Key TakeAways

In this article, we discussed the introduction of the REST protocol for web services.

1. The REST (REpresentational State Transfer) is a standard that operates between machines mostly executing web services.
2. The server receives a request in form of REST API. The server then runs the web application and sends a response to the client.
3. For an API to be a valid REST API (RESTful API) it needs to fulfil some constraints that we discussed above.
4. A RESTful API adheres to these constraints (also called guiding principles).