REST Services & REST Architectural Constraints

What is REST Service?

REST was first defined b Roy Fielding in 2000. It stands for Representational State Transfer(REST). Actually, REST is an architectural model and design for server network applications.

REST is used to build Web services that are lightweight, maintainable, and scalable in nature. A service which is built on the REST architecture is called a RESTful service. The underlying protocol for REST is HTTP, which is the the basic web protocol.

REST stands for REpresentational State Transfer. Resources are identified by an URI and URIs may refer the same resource. It is use for client and server communication.

REST does not enforce any rule regarding how it should be implemented at lower level, it just put high level design guidelines and leave you to think of your own implementation.

REST Architectural Constraints

01.Uniform interface

As the constraint name itself applies, you MUST decide APIs interface for resources inside the          system which are exposed to APIs consumers and follow religiously. A resource in the system            should have only one logical URI, and that should provide a way to fetch related or additional            data. It's always better to  synonymize a resource with a web page.

Any single resource should not be too large and contain each and everything in its representation. Whenever relevant, a resource should contain links(HATEOAS) pointing to relative URIs to fetch related information.

Also, the resource representations across the system should follow specific guidelines such as naming conventions, link formats, or data format (XML and JSON).

All resources should be accessible through a common approach such as HTTP GET and similarly modified using a consistent approach.

"Once a developer becomes familiar with one of your APIs, he should be able to follow similar approach for other APIs."

02.Client-server

This essentially means that client application and server application MUST be able to evolve separately without any dependency on each other. A client should know only resource URIs, and that's all. Today, this is normal practice in web development, so nothing fancy is required from your side. Keep it simple.

Uses URI to make the connection between two, and clearly separately UI and services. HTTP stack is the communication platform.

"Servers and clients may also be replaced and developed independently, as long as the interface between them is not altered."

03.Stateless

Roy fielding got inspiration from HTTP, so it reflects in this constraint. Make all client-server interactions stateless. The server will not store anything about the latest HTTP request the client made. It will treat every request as now. No client state on the server, and server is not needed to keep the server information or session details to itself.

If the client application needs to be a stateful application for the end-user, where user logs in once and do other authorized operations after that, then each request from the client should contain all the information necessary to service the request – including authentication and authorization details.

"No client context shall be stored on the server between requests. The client is responsible for managing the state of the application."

04. Cacheable

In today's world, caching of data and responses is of utmost important wherever they are applicable/possible. The webpage you are reading here is also a cached version of the HTML page. Caching brings performance improvement for the client-side and better scope for scalability for a server because the load has reduced.

In REST, caching shall be applied to resources when applicable, and then these resources MUST declare themselves cacheable. Caching can be implemented on the server or client-side.

"well-managed caching partially or completely eliminates some client-server interactions, further improving scalability and performance."

05.Layered system

REST allows you to use a layered system architecture where you deploy the APIs on server A, and store data on server B and authenticate requests in Server C, for example. A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way.

Client only deals with the abstraction of resource URI and verb, and highly scalable. 

Layers can be added, removed, modified, or reordered as the architecture evolves.

06.Code on demand

Well, this constraint is optional. Most of the time, you will be sending the static representations of resources in the form of XML or JSON. But when you need to, you are free to return executable code to support a part of your application.

It allows clients to improve its flexibility because in fact it is the server who decides how certain things will be done. With Code-On-Demand, a client can download a JavaScript, java applet or even a flash application in order to encrypt communication.

Eg:- clients may call our API to get a UI widget rendering code. It is permitted.