REST is a pretty common term that you will encounter now and then in web development. REST stands for Representational State Transfer. These are a set of core principles for architecting your software(mostly web services). Initially introduced by Roy Fielding in his PhD dissertation, here I will try to explain in brief what those principles are, what it means to be RESTful, it's different use cases and how HTTP comes into the picture.
Before getting into REST, we need to look at HTTP quickly. HTTP is an application layer data communication protocol on which(most of) the web works. This protocol defines how messages are formatted and transmitted and what actions web servers and browsers should take in response to various commands.
HTTP defines a set of methods to perform any action on a given resource. It has a pretty rich set of status codes which makes life way easier for a developer. There are various sophisticated features, also such as authentication, caching, cookies, etc.
So you see REST is a way of architecting your application and HTTP is the protocol which defines how your application(web services) should be built. One can think of RESTful web services as such services which follow the REST guidelines. HTTP is merely an instantiation of the REST guidelines. Your application built on top of HTTP might be perfectly RESTful, partially REST or kind of 60% REST.
It is very subjective how close is your software to being perfectly RESTful. Let's see what should be the common characteristics in all RESTful applications.
Every resource(objects) must be uniquely identifiable by a URI. URI stands for Uniform Resource Identifier. Objects could be anything from multimedia objects(images, videos, gifs, etc.) to text files, database rows, etc. Anything that has merits to be identifiable gets a URI. There should be a single consistent naming of the resources. Here the developer should think what the right resources in your application are.
These resources should contain links to other resources. Linking them is based on the fact that each has a unique ID. For example, you enter an address in your browser and get a web page(a resource) which links you to other resources. Representational resources link to each other.
REST says you should have the same set of methods for all resources(uniform interface). HTTP makes this specific by its methods
DELETE, etc. So you see these methods define what action you could perform on the resources. REST defines these in a very general context. For example
GET should be safe, idempotent and cacheable on all the resources. Similarly, there are semantics associated with other methods. It is possible that we could have more such methods, maybe in some other instantiation of REST. That point is REST doesn't hold you back from having several methods on resources. But it should be consistent over the different type of resources.
You interact with the resource through their representation only. For ex. if there is a customer resource identifiable by some URI. If you
GET it in
text/HTML format it should return you that format, or if you get it in
application/XML format, that should also work. RESTful web services allow you to interact with the same resource in different representations.
The server does not store any state about the client session on the server side. Let's see it by an example of a shopping cart on an e-commerce website. You can add items to your cart, and you can delete items from your cart. A shopping cart can be implemented in many ways. In one implementation, the server could send a link to your shopping cart. Because it is a resource and identifiable by a URI and also it can be linked to other resources. In another implementation, the shopping cart could be an unnamed client-specific state(session state). So REST says you should go with the first one.
Well, you have other options also such as GraphQL. If you follow REST guidelines, then you can derive your application-specific interface from the REST specific interface. While doing this, the developer takes care of not violating the semantics associated with the HTTP methods. Following REST lets you decouple your application also. Your client could be anything. It can be a browser, a terminal, another apache web server, proxy, etc. The client knows what result that its action is going to produce on the resources if the server is RESTful.
For example, let's say a client is searching for some resource on the server. If you have followed REST, then you have pretty robust
GET on all the resources which return a readable representation of that resource. So that will let your client build fast and efficient search algorithms.
The SE-Radio Podcast with Stefan Tilkov inspires this blog. I tried to present the learnings in a brief, concise way. If you have any doubt or you find anything to add, please comment below. I would love to hear your thoughts on this.