Web Services (What are REST Web Services)-Part(5)

In the previous tutorial, we learned about the first principle of REST. Here we are going to talk about the remaining principles of REST.

Web Services (What are REST Web Services)-Part(4)

Let us begin with Stateless REST

Stateless REST — (Principle 2)

(All client-server communications are stateless)

In our RESTfull architecture, we say that all the requests, responses and all the communication between client and server are stateless. This means that the server does not maintain any state of the system and the client has to send a request which is completely independent it does not depend on any other previous requests.

• The server should not require to store the state of the session.
• If the concept of a session is required all information should be stored at the client-side and sent with every subsequent request.
• This makes every request call from client independent and a complete entity in itself.

Example: If a person adding items to his cart on a shopping website, the state of the cart should be stored at the client-side only. And this state of the cart has to be sent from the client to the server whenever required. And how does this happen? We will talk about that in the next principle Caching.

So finally each request from the client to the server must contain all of the data that us necessary to handle the request. No need of storing any state on the server. This improves WEB SERVICE PERFORMANCE.

Caching — (Principle 3)

In the previous concept, we saw that the server does not maintain the state of the session. In that case how the client and the server communicate when passing requests and responses. For that, we can use caching and the caching happens at the client-side. So whenever a client sends a request to the server the server gets that request which contains the actual data and along with the actual data, there is some other metadata (some information in the headers) and which tests the client whether the client has to cache the response or not.

So the server generates a response that indicates whether they are cachable or not too important by reducing the number of requests for the duplicate resources.

Let us see an example of the response

This is the response of the server. Deeply look at the headers and you can see that there is a Cache-Control header which tells that what is the maximum time that this message should be cached and then also see an Etag here.

Etag is an entity tag and every unique version of the response has a unique entity tag. If the resource changes there will be a new entity-tag tagin to that particular representation. So with this, we can do Caching.

So that client uses the Cache-Control header to determine whether cache the resources or not. In RESTful Web Service this co-ordination between Client and Server is essential for being Stainless. So this is the concept in caching.

Layering — (Principle 4)

The communication between Client and Server 4th Principle says that there can be multiple layers between communication. These layers can be HTTP intermediaries and they can be used for a number of purposes. They can be used for message translation, improving performance, caching, etc.

We can also have layers like Proxies and Gateways. A client may send the request to a proxy server(instead of the main server). Then Proxy server evaluates the request to simplify or control its complexity. The gateway may be used for managing traffic on the network, proxy translation, etc.

We can also have some layers which can help us in caching.

Example: We use a layer (intermediary) that can cache a response and store it for an hour. If a request comes from the client within an hour, the cached response will be sent from the intermediary(without going until the server). This improves performance and scalability.

The layered constraint was added to address improving internet sized scalability requirements. Each layer cannot see beyond the immediate layer with which it is communicating with. This places boundaries on the overall complexity of the system. Like most solutions for scalability, there are usually trade-offs. Latency is increased with the introduction of layers but the cache-constraint above can certainly help reduce the amount of request over the network.

Code-on-demand (Principle 5)

This is an optional constraint of REST Web Services. So it is something like when you send a request and get back the response. The response has an ability to run some code or some JavaScript on the client-side.

This allows the client to be extendable by downloading and executing code. Similarly to Java Script in a web browser, this allows you to add functionality without re-deploying client software.

Example: The client requests a resource and Server returns resource with some Java Script.

I hope now you have a basic idea about What is REST and the principles of REST.

Summary

REST means that every resource can be represented in multiple ways. So resources have a representation in XML or JSON format.

Whenever the Client release a request the representation of the current state of the resource is transfers between the Client and the Server.

Example: Do a GET request from the image's resource. I want to retrieve the Image 1. The representation requesting is JPG. So that I will get a response with a JPG representation of the resource. Now if I again do a request to image’s resource. But this time I want XML representation. Now I will get a response with the XML representation of the resource.

Now you can understand representation is the description of the current state of the resource and we can have multiple representations of the resource.

Finally, I hope all 5 principles and the REST are very clear now.

Thank You!