Everyone talks about RESTful APIs. Everyone use RESTful APIs. It even seems like, everything has RESTful APIs.
You may already know that many of the tech giants like Google or Facebook offer RESTful APIs for many of its services. Almost every developer make use of these RESTful APIs.
It is so simple, invoking a RESTful API you may say. Just do a GET, PUT or POST request to get a response JSON. Then we are done.
But what exactly REST means?. Is it the API?.
Then what is a RESTful API?.
It seems like most of us started with a GET operation, but did not pay much attention to the name itself. And now it has been so long, we never really ask these questions.
But it’s always very important to get the basics right so that we will not be confused with such simple questions.
So let’s explore together, to resolve this tiny mess!.
What is an API?
Before we step into anything, let’s talk a bit about an API.
As we are going to learn in the following sections, REST is an architectural style to design an API. Therefore, let's have a look at the basic idea of what is an API.
An Application Programming Interface a.k.a an API, allows one component to communicate with another.
Most of the times you hear these web-based APIs, where you can do some operations and get some JSON or XML data from it.
An API behaves as an access point to an application. Another application can use this access point to interact with this application.
Imagine a web server exposing a database as illustrated in the image above. This web server presents an API allowing other applications to perform CRUD operations in its database. Anyone wants to perform a CRUD operation does not need to know how the internals of the web server behaves, but just to tell the API to perform the operation for him.
The Origin Story of the REST
Before 2000, there was not really a standard existed to build an API for a system. Back then, the solution was to use a protocol like SOAP, to create an API.
If you have ever used a SOAP based API before, you would know how complex it is. For those who haven’t touched SOAP, this is an API protocol for exchanging structured data, which is built for flexibility. But due to its nature, building and handling of a SOAP based API is extremely difficult.
In 2000, a guy name Roy Fielding proposed a whole new architectural style called “REST”, to design APIs, in his Ph.D. dissertation.
Intentions of this new architecture style are simple. An API will provide a simple but yet powerful communication between components. The interface between components will be uniform. Also, the components are allowed to be managed separately, allowing them to be scalable, reliable, portable and modifiable.
In his words, Roy later told that he had to explain his idea about this new architectural style, with the most basic concepts while presenting to a group of experts for his Ph.D. dissertation. This eventually leads Roy to come up with a set of constraints, governing REST.
REpresentational State Transfer, a.k.a REST
REST is nothing but an API architectural style with a set of constraints. Any system built with REST APIs maintains below-mentioned constraints defined in the REST architecture.
Client-server architectureStatelessnessCacheabilityLayered systemCode on demand(optional)Uniform interface
APIs satisfying REST constraints are called as RESTful APIs.
I will not explain each of the constraints above, which will surely break our flow for this article. But they are explained nicely in this Wikipedia article[1]. Anyone interested can go ahead and read it.
However, I am going to explain a few of the constraints from above, to answer the important question.
Why is it called REpresentational State Transfer? What does this mean?
A REST API has the client-server architecture constraint. This separates the server from the client to improve the scalability.
The communication between the client and the server is Stateless. This is another constraint defined in the REST definition. This means,
No client state is stored within the server.Each request made from the client contains all the information requires to process that request.Once the request is processed, the new server state is sent back to the client, using as a REpresentation of the server state.The client will make the next request when its ready to make the transition to the next state.
Now let's collect these together.
In its client-server architecture, a REST API will transfer server-state as the response to a client request. Nothing is stored in the server for the client state. The client will act based on the transferred state it received from the server for future requests.
Here, a server will transfer its state using a representation. For an example, a server could send its state data to the client from its DB, using a JSON. Data represented by this JSON is not equal to the internal representation of the DB.
This is what we see, during the GET, PUT, POST operations with REST APIs. With each of the operations, JSON payloads are sent and retrieved from the server. This is server transferring its state for each client call, telling the client that this is where I am now. Client will then say, ok do this for me or get this for me. Notice that the server will never say, this is where I am now, do this with the next request to the client. This is because of the stateless nature of the server in REST.
The nature of transferring server state using representations during its client-server communication gave the REST its name, REpresentational State Transfer.
That’s it!. Now we have a general understanding of what REST is and why its called like that. I hope this helps to get the big picture on REST, rather than looking it as a set of GET, PUT, POST calls.
Of course, this article does not explain REST in detail. But I hope that this just gave a good point to start on learning REST in detail.
Wrap-it-up
In this article, we started with a simple question of, what does REST mean. We basically deal with some endpoints and JSON payloads but didn’t really understand what REST is. Then we started with what an API is. An API is used to communicate between components. Then we moved on to the REST, which is an architectural style to design an API. We did explore how the REST concept was originated and the constraints define it. Then we understood that in its client-server architecture, REST transfer server state for each client call to stay stateless and this is what gave REST its name, REpresentational State Transfer.