What is REST?
REST stands for Representation State Transfer. REST is a set of constraints that were put forth by Roy Fielding. You may find that these constraints are hard to grasp with all theoretical discussion. At this point let us just try to go through the constraints one by one. However, we will get into practical understanding of these constraints later tutorials.
REST Constrains
1) Client – Server Architecture style
This is the first constraint in the REST architectural style. According to this constraint, an application should be modeled like a Client – Server. To relate to it, application should have the UI separate from the Data. There should be a distinct component handling Front end (UI) and the Back end (Database).
From our earlier chapter on Client-Server Architecture, UI here will act as a client and the back-end will be the server.
The importance of this style of design is that the Client and Server components can evolve independently. Also, most important part is that a Server can serve multiple Clients, Clients can further be on different technologies.
2) Stateless
This is the second constraint in the REST architectural style. According to this constraint a Server should not store context of the Client. Each request sent by the Client should not be treated with any information (context) from previous requests made by the same client.
The importance of this constraints is that because of it Server implementations becomes simple. It now doesn’t need to store references of clients.
Also, all the requests made by clients should be contain all the information required to service a request. We will see this constraint with example as we learn more about REST in coming tutorials.
3) Cache
This is the third constraint in the REST architectural style. According to this constraint Responses from the server should contain relevant information to tell whether the Response can be cached by the client of not. Usually this is done via a Header entry in the Response.
This constraint improves the client efficiency, for cacheable responses Client need not make requests to the server. Client can simply look into its cache for the Response. This save network bandwidth and Client processing power.
We will see this in detail as we learn more about REST in the coming tutorials.
4) Uniform Interface
The uniform interface constraint is fundamental to the design of any REST service. The uniform interface simplifies and decouples the architecture, which enables each part to evolve independently. The four guiding principles of this interface are:
- Identification of resources
- Manipulation of resources through these representations
- Self-descriptive messages
- Hypermedia as the engine of application state (A.K.A. HATEOAS)
5) Layered System
This is the fifth constraint in the REST architectural style. According to this constraint the system implementation should be layered. Each layer abstracting out certain functionality of the overall system. A layer should not know about the existence of other layers apart from the layers that it directly interacts with.
Layered software design is a common practice outside the realm of REST too. This constraint decreases the overall complexity of the different components within the system. As we have to deal with relatively smaller and logical cohesive pieces of functionality it becomes easier to implement layers.
6) Code on demand
This is an optional constraint that RESTful architecture imposes. According to this constraint a client can extend its functionality by downloading code from the Server This code can come in the form of Applets or Scripts. Javascript is one example of how code on demand can help clients extend their functionalities.
With the ability of a Server sending code to the Client, comes the security concerns.
