REST (Representational State Transfer) is an architectural style for designing web services. REST provides a set of principles that define how Web standards, such as HTTP and URIs. are supposed to be used. When we follow the REST principles in designing our applications, these applications basically use Web’s architecture and get all benefits that come with it. These principles say:
We need to think in Resources
Resources are the fundamental building blocks of the web-based system. A resource can be anything that we expose to the Web. It can be a document or movie clip or a product or a business process.
To use a resource like interacting with it on the network or manipulating it resource needs to be identifiable which means resource should get an ID. The web provides the URI (Uniform Resource Identifier) for this purpose.
A URI uniquely identifies a web resource and at the same time makes it addressable. Here are some examples of the URIs:
A resource’s URI distinguishes it from any other resource. It gives us an opportunity to manipulate it using an application protocol such as HTTP.
The relationship between URIs and resources is many to one. A URI identifies only one resource, but a resource can have more than one URI just like a human can have more than one email address or telephone number.
Even though the above figure shows three representations with three URIs, multiple resource representations can be addressed by a single URI. Using content negotiation, consumers can negotiate for specific representation formats from a service. Consumers can use HTTP Accept request header with a list of media types they are prepared to process.
A resource must have at least one identifier to be addressable on the web, and each identifier is associated with one or more representations. A representation is a transformation or a view of a resource’s state at an instant in time.
It is important to remember that a resource can have one-to-many relationship with its representations.
Resources needs to be linked together
When we browse the web to buy something, we navigate different page(s) by clicking links or completing and submitting forms. What we do basically, we perform a set of steps to achieve a goal, in this case to buy a product. It is the core concept of hypermedia: by transiting links between resources, we change the state of an application. There is a formal description of it: Hypermedia as the engine of application state (HATEOAS). The benefit of the link approach using URIs is that the links can point to the resources that can be provided by a different application, a different server, or event a different company.
Server provides a set of links to the client that enables the client to move the application from one state to the next by following a link. Links make an application dynamic.
Use of standard HTTP methods
The standard HTTP methods like GET, PUT, POST, DELETE need to be used correctly in order to make the clients interact with the resources. These are also called HTTP verbs. Their meaning along with some guarantees about the behavior is defined in HTTP specification. For example, GET should be used to retrieve a representation of a resource. GET is safe and idempotent which means a same request to get a representation can be issued multiple times. PUT is for updating a resource with the data or create it at this URI if it is not there already. DELETE is for deleting a resource. Both are unsafe but idempotent. POST is for creating a new resource which is neither safe nor idempotent.
When a safe method is invoked, the resource state on the server remains unchanged. An idempotent method can be invoked multiple times, the end result is the same.
Following the HTTP methods correctly is important because this makes our application part of the web.
In REST, the server should not have to retain some sort of communication state for any of the clients it communicates with beyond a single request. It decouples the clients from the server which improves the scalability.