The Introduction

We all know how the web works. Clients (such as web browsers) send requests to a server. Browsers do not know beforehand about the server and its resources and the server responds with the content requested.

You open every website in the same way, by just typing in the URL. You don’t give a thought to where your resources are and how they are fetched for you.

This is interesting and easy. Right? Unfortunately, that’s not the case if it’s not the web.

You would know this if you have ever tried accessing information from some other system in your network. You may have used virtual machines and accessed them using mstsc or any other tools. You have to particularly look for a file on that machine. It is just not fetched for you.

So, what makes it possible in the case of WEB? The answer is its architecture, REST.

To make webpages REST compliant, one must adhere to SIX constraints.

The Big Picture

For a moment, let’s forget machines and talk about humans. Assume that humanity has a single goal, and all men, women, and children are working towards that goal. The goal is:

“I want to be able to talk to anyone in the world. I want to be able to respond to anyone in the world.”

Let us follow the sequence of results we would need to meet the goal:

The Common Core

So, towards that goal, we need a base tool. The tool is a common language that all will be able to speak and understand. But you cannot just talk to everyone by speaking. That brings us to the next result.

The Medium

So, as distances increase, you would need a medium. Our next tool can solve the problem: the telephone. Now a common language is decided and the telephone network is set up. This brings us to the final piece of the puzzle, implementation.

The Conversation

Not everyone may know the common language. For our purposes, let us assume its English. Everyone agrees to initially learn only a few words of English, allowing each to understand simple questions and respond to them. They identify and agree upon some common codes in English, meaning to which is known to all.

Now it’s a bit simple, isn’t it? But you see, these small steps and results bring in a whole new era.

The Outcome

You can now talk to anyone in the world. Initially, the conversation may be limited, but you can still get your point across. As everyone is connected, he/she can refer you to someone else who they know can answer your question. As time passes, you can safely assume that others will gradually learn more about the language. Eventually one day, everyone will share everything with anyone around the world.

And that is how, humanity, will meet its goal.

The REST Shall Set You Free

The human implementation was just an example. However, the same thought was behind the creation of the REST architecture. With REST architecture, we wanted that all machines in the world be accessed. Consequently, they would respond because they would know what is being queried. And if they don’t have the necessary information, they would provide the URLs to other machines that have it. This gradually evolved with time.

Now think about all the computers in the world. They needed to talk to each other or share information with each other.

• They used a common way that all others understood, web, a client/server architecture, where every machine that requests is the client and every machine that responds is the server.
• They have agreed to use a common medium to share information like you used. HTTP. Now HTTP is synonymous to the telephone and URLS are the telephone numbers.
• They have agreed to use common terms/words GET, PUT, DELETE, and POST, things that all machines understand.
• Files such as XML, HTML, and JSON are the actual representation of resources.

The Technical Mumbo Jumbo

Now to make webpages REST compliant, one must adhere to SIX constraints which ultimately protects the simplicity of the restful web services architecture explained above. The six constraints of a restful architecture are as follows:

Uniform Interface

• Acts like a contract for communication between clients and servers
• Http verbs – GET, PUT, DELETE, POST
• URI/URL: Each resource must have a specific and cohesive URI to be made available

  HTTP/Hypermedia—Any HTTP request should be responded with meta data and all the necessary information in response so that the client knows how to navigate and have access to all application resources.

Stateless

State here means that,

One client can send multiple requests to the server and each request is independent and complete in itself. It must contain all of the information necessary to understand the request. In other words, for every request no session state in stored on server.

• Server contains no client state
• Session state is held on client

Cacheable

• Representation/Response is cacheable, avoiding unnecessary processing and significantly increasing performance
• Client-Server

Disconnected

• Server waits for client requests, performs these requests, and gives back a response
• Uniform interface is the link between them

Layered System

• No direct connection can be assumed between the client and server
• It can be a load balancer or any other machine that makes the interface between server(s)

Code on Demand (optional)

• Java applets /script may also download with webpage

Violating anything other than code on demand is a violation of RESTful.

The End: RESTful architecture services

Now, have you ever heard of the term RESTful web services? The idea behind RESTful web services is the same as above, but humans are replaced with machines. REST is designed for humans. What if a machine can access any information over another machine just like humans do through a browser? And yes, it is possible. The answer is REST based web services.

RESTful web services are designed in such a way that any machine can access information over a network with the help of endpoints that represent resources.