Understanding HTTP: The Backbone of REST
To understand the REST architecture, it is very important that we understand the HTTP clearly because all the http protocols are used while building a REST API.
HTTP is all over the internet. Every time when we hit a URL in our browser, an HTTP request is sent to the webserver and we receive the HTML content in response. An important thing to note here is that, while the website is usually for the human consumption the REST Api is usually for application consumption.
Therefore, while requesting the data from a website, the data should be in a browser readable format, which is HTML, while in case of the REST API, response can be anything like XML/JSON or any other media type.
Since REST is very much inspired by the HTTP, HTTP can be said as the backbone of the REST.
HTTP is a TCP/IP based communication protocol, which is used to deliver data (HTML files, image files, query results, etc.) accross the World Wide Web.
One very important point about REST is, that it is not connected to web, and will return no response when tried to access via a browser, although it is based on HTTP.
Basic Features of the HTTP
As we have already learnt HTTP is a protocol which allows us to send files back and forth on the web, which involves a client and a server. HTTP is text based, which makes it easier to monitor.
The basic features of HTTP are:
- 1. HTTP is connectionless.
- 2. HTTP is media independent, which means any type of data can be sent through the http.
- 3. HTTP is stateless, neither the server nor the client keeps a track of the last request.
HTTP makes use of the Uniform Resource Identifier (URI) to identify any given resource and establish a connection. HTTP request and response, use a generic message format of RFC 822 for transferring the data.
The generic message of any HTTP request and response, consists of the following four items:
- 1. A start line
- 2. Zero or more Headers
- 3. Empty line indicating the end of the header fields
- 4. and, Optional message Body.
HTTP header holds the metadata and information about the HTTP method, while the body contains the data that we want to send to the server.
We can check the HTTP requests as we surf on the Internet. If you use Chrome Browser, press F12 in Windows, and Command + Option + I in Mac OS to open developers tool. Under the Network tab, you can see the HTTP request made, and the response received along with the headers.
REST and HTTP
URL stands for Uniform Resource Locator. Yes, a webpage is also a resource and is loaded by sending a request to the associated URL.
Let's take a general example, an application which manages college's students data.
/students
The above URL will return all the students data in response. While,
/students/saurabh samir
will only return data for the student with name saurabh samir, if its unique.
Whenever we call a REST service, we generally don't mention the HOST NAME, like in the above example URLs, but hostname is very important to make the URL unique all over the web. The header generally has the hostname in it.
GET students/saurabh samir HTTP/1.1 HOST: learnfrenzy.com
NOTE: While creating a RESTful architecture, keep in mind that resources are thought to be as Nouns, so try to keep it that way. For example, the following is not RESTful:
/students/add
You must be wondering that this looks ok, as we can send the data to be added in HTTP request body, but, in RESTful architecture, we do not use URLs to describe actions.
In REST, /students will be the resource, and the action will be decided based on the HTTP verb used. Based on the HTTP verb, we inform the service, whether to create a new student entry, update the existing one or delete it, using the same resource.
Sample Start Line
GET/hello.htm HTTP/1.1 (sent by client) HTTP/1.1 200 OK (sent by server)
Header Fields
Generic Header
[field-name] : [field-value]
Check the snapshot of Chrome's developers tool above to see sample header.
Message Body
The message body is optional and this is the one, which carries the actual HTTP request data from the client and the response data from the server. Here is an example of getting back HTML in response in body.
<html>
<body>
<h1>Welcome</h1>
</body>
</html>
HTTP Methods/Verbs
The most important part of a request is the HTTP Method (verbs). These methods tells the server what to do with the data received in the request. You must be familiar with GET and POST as they are frequently used in FORM submission in HTML.
Although there are 8 different types of methods but the 4 most important HTTP methods will be discussed here which are equivalent to the CRUD operations.
GET
The GET method is used to get the information from the server. This is equivalent to the SELECT statement in SQL. There is no message body in the GET request as it is meant to only fetch the data from the server.
This is the simplest type, and is used by the browser every time you visit any link, to fetch the data. A GET request should never change the data on server, and should only be used to read data.
GET /students
The above should return the students data.
POST
This is used to send the data to the server. This can be students information, some XML file or some JPG file. The message body contains the data. POST requests are generally used to create but it can be used to update the existing data as well.
POST /students
The above should be able to create a new student entry, provided student data is sent in appropriate format in the message body. This can be used to update student data as well.
PUT
This should be used when we have to replace/update/create the data, which is already present/not present on the server with the data that we pass in the message body.
DELETE
This should be used to delete the data on the server. For example, the following URL when sent a DELETE request, should delete the student entry.
DELETE /students/saurabh samir
You must notice that, with every method, we have mentioned should be used, as we can only advice to follow the standards. Just saying, but DELETE can be used to create a new entry, but we must follow the standards to avoid any confusion.