The term REST, (Representational State Transfer) was introduced in way back in year 2000, by Roy Fielding in his doctoral dissertation at UC Irvine. Though it is about 16 years ago, still it’s importance is more or less the same. REST introduces an architectural style for web applications.
REST is tightly coupled, and embraces the potential of HTTP. Because of that it has become more popular in web application domain. REST see a web application as a virtual state-machine where states are different web pages; progressing user from one state to another through links; and going to another state.
To call be a web application RESTful, it needs to comply certain constraints. Following those constraints also helps web application to have desirable non-functional properties as well.
Decoupled client-server interaction
There should be a uniform interface to separate client and server, which helps to achieve separation of concerns. Client has no need to store data, such that client is portable. On the other hand, server does not worry about keeping user state, so server-side can be scaled. In RESTful architecture server and clients should be able to use different technologies to develop separately.
Going further with client-server architecture, the server should not keep client context between requests. Each request from client should include all the information necessary to serve that request. Session state is held at client side. Once session data is received, the service can transfer that to another service.
Each state of application contains the links for client to choose the next state transition.
The client may connect to intermediate layers, which might not aware before-hand. So those layers can enforce security, do load balancing, provide caching etc.
Response from server can be cached at client side and at intermediaries, as defined by HTTP response. Cache-Control Header plays a key role in that behavior .
Extensible through code on demand
This a basic requirement of a RESTful service and helps to make decoupled client-server interaction.
- Identification of resources
Server can use requests to identify resources separately (eg: URI), and returns the representation of that resource to client (as HTML, XML or JSON).
- Manipulate the resource through its representation
The representation send by the server is enough for a client to manipulate (update, delete) that resource.
- Self-descriptive messages
Information included in a message contains adequate information on how to manipulate that message.
- Hypermedia as the engine of application state (HATEOAS)
“Hypermedia, an extension of the term hypertext, is a nonlinear medium of information which includes graphics, audio, video, plain text and hyperlinks” 
So clients can only make transitions, through actions that are dynamically identified within hypermedia by the server. There are no standard format to represent links in a hypermedia, but there are few popular ones .
The constraints helps you to achieve following properties;
- Simplicity of interfaces
Web service APIs that comply with REST architectural constraints are called RESTful APIs .