REST architectural constraints

REST is a distributed network platform that uses Web protocols and technologies. The REST architecture includes client and server interactions built around resource transfer.
Additionally, online publishers use REST by enabling Web page content and XML statements while delivering syndicated content to users. Users can access the web page through the URL of the website, read the XML file with a web browser, and interpret and use data as appropriate.

Constraints in REST

There are 6 constraints in REST. Such constraints limit the way the server can manage and respond to client requests, such that the system achieves desirable non-functional properties such as consistency, scalability, usability, editability, accessibility, portability and reliability by working within these constraints. If a system violates any of the necessary constraints, it cannot be called RESTful.

1. uniform interface
2. client-server
3. stateless
4. cacheable
5. layered system
6. code on demands

Uniform interface

As the name of the constraint itself applies, you MUST determine the APIs interface for resources within the network that is exposed to and faithfully followed by API users. A device resource should have only one logical URI, and that should provide a way to get relevant or supplementary data.

Client-server

This basically means that applications for clients and servers Should be able to develop independently without any reliance on each other. A client should only know URIs for resources.

Stateless

If the client application needs to be a stateful application for the end-user, where the user logs in once and then conducts other approved operations, then each client request will include all the information required to support the request–including authentication and authorization details.

Cacheable

In REST, where necessary, caching must be applied to resources, and then those resources MUST declare themselves cacheable. Server or client-side caching may be applied.

Layered system

REST allows you to use a layered system architecture to deploy the APIs on server A, store data on server B, and, for example, authenticate requests in server C. A client can’t normally say whether it’s directly connected to the end server, or to an intermediary along the way.

Code on demand

The constraint is optional. Most of the time, you’ll send the static resource representations in XML or JSON format. But if you need to, you are free to return executable code to support a component of your application.