Understanding REST

There’s a high chance you might have come across the word “REST” if you’ve thought of getting data from another source. But what is REST? What can it do for you?

In this blog, you will learn everything about REST.

What is REST?

REST stands for Representational State Transfer. It is a software architectural style followed when designing APIs. It proposes a set of rules web developers should follow when building APIs. REST was discovered by Roy Fielding and was presented first in 2000 in his famous dissertation. JSON or XML is used to pass the data. REST is lightweight, scalable and maintainable.

The 2 main important rules we should follow when designing RESTful services are:

1. Use HTTP Request Verbs to make requests.

2. Use specific patterns of routes/endpoint URLs to make requests.

HTTP Request verbs

There are 5 HTTP request verbs that should be used while making requests.
They are:

1. GET: Used to fetch a new resource

2. POST: Used to insert a new resource

3. PUT: Used to replace an existing resource

4. PATCH: Used to update an existing resource

5. DELETE: Used to delete a resource

Why REST ?

At present, there is a huge number of technologies used when developing programs. So it is not possible for a developer to know all the programming languages. So there should be a simple lightweight method to communicate between client and server irrespective of the platform. Therefore REST enables web applications that are built using various programming languages to communicate with each other. No matter what the environment is they will be able to communicate using REST. RESTful web services allow applications written in a variety of programming languages and platforms to communicate with one another.

The second main reason is applications are slowly moving to the cloud and these cloud providers provide a lot of API’s based on the RESTful architecture. Because all Cloud-based architectures are built on the REST concept, it makes more sense to program web services using the REST services architecture to get the most out of Cloud-based services.

Constraints of REST

REST, like every other architectural form, has its own set of six governing constraints that must be followed if an interface is to be considered RESTful. These constraints are discussed below.

1. Client Server — The most fundamental requirement of a REST-based architecture. This constraint means that the server will have a RESTful web service that will provide the client with the requested functionality. The client sends the request to the web service on the server. The server would either reject the request or accept the request and respond to the client. This clearly separates user interfaces and services, making the client portable. The server stands independent from different user interfaces and the client does not have any connection to the data server. HTTP stack is used as the communication platform to send requests and responses.

2. Stateless — The server doesn’t store the state of the client. The session state will be kept on the client-side. Therefore, each request from the client to the server must include all of the information required to understand the request. This is necessary so that the server can properly process the response. This is a simple question-answer scenario. The client asks a question by providing all the necessary information and the server responds with the answer. The server will respond to each scenario independently and doesn’t remember the previous question-answer scenario.

3. Cacheable — REST services should be cacheable. This concept is used to help with the problem of stateless. Because each server-client request is independent, the client may ask the server for the same request several times. So again the server will respond to the same request asked by the same client. Therefore, this might increase traffic in the network because of sending the same request again and again. Therefore this cacheable concept is implemented on the client to store requests which have already been sent to the server. Therefore if the client makes the same request, instead of going to the server, it will go to the cache and retrieve the information needed. This reduces the amount of network traffic between the client and the server.

4. Layered System — Any extra layer, such as a middleware layer, may be placed between the client and the real server hosting the RESTFul web service in a layered system. But this should be transparent ( the client does not see the underlying layers or complexities ) so that it does not disturb the interaction between the client and the server. The client only knows the URI and doesn’t have any idea about the distribution of the server. Therefore the server is highly scalable.

5. Uniform Interface — A uniform interface between components so that information is transferred in a standard format. It is the underlying technique of how RESTful web services should work. HTTP web layer is the underlying layer of RESTful web services and HTTP verbs are used to communicate with resources on the server.

6. Code on demand — This is an optional constraint. The client functionality can be extended by sending executable code from the server to the client when requested in the form of applets or scripts.

These 6 constraints need to be fulfilled for a service to be RESTful.