What is RESTful Services and its constraints

REST was a word coined by Roy Fielding in his Ph.D. thesis meaning Representational State Transfer. It is an architectural design that relies heavily on the use of hypermedia to transmit information from one system to another. Its whole engine is based on the concept of Hypermedia As The Engine of Application State (HATEOAS). So, what constraints make a service a fully RESTful service. To Know more about REST refer restapitutorial. In this there is six key constraints are,

1. Client-Server
2. Stateless
3. Cache
4. Uniform Interface
5. Layered System
6. Code on Demand

1. Client-Server

A service is indeed RESTful if there is a separation between the client presenting the view and the server computing the logic of the application. A service is indeed RESTful provided a separation of concern exists between the layer of the client and the server. The relationship of the client and server is such that the client and server can exist independently communicating only through hypermedia calls and implementation. This feature makes RESTful services fundamental in our today’s world where the division of labor between the client and server is becoming more obvious and fundamental.

2. Stateless

As REST is an acronym for REpresentational State Transfer, statelessness is key. Essentially, what this means is that the necessary state to handle the request is contained within the request itself, whether as part of the URI, query-string parameters, body, or headers. The URI uniquely identifies the resource and the body contains the state (or state change) of that resource. Then after the server does it’s processing, the appropriate state, or the piece(s) of state that matter, are communicated back to the client via headers, status and response body.

Most of us who have been in the industry for a while are accustomed to programming within a container which provides us with the concept of “session” which maintains state across multiple HTTP requests. In REST, the client must include all information for the server to fulfill the request, resending state as necessary if that state must span multiple requests. Statelessness enables greater scalability since the server does not have to maintain, update or communicate that session state. Additionally, load balancers don’t have to worry about session affinity for stateless systems.

So what’s the difference between state and a resource? State, or application state, is that which the server cares about to fulfill a request—data necessary for the current session or request. A resource, or resource state, is the data that defines the resource representation—the data stored in the database, for instance. Consider application state to be data that could vary by client, and per request. Resource state, on the other hand, is constant across every client who requests it.

Ever had back-button issues with a web application where it went AWOL at a certain point because it expected you to do things in a certain order? That’s because it violated the statelessness principle. There are cases that don’t honor the statelessness principle, such as three-legged OAuth, API call rate limiting, etc. However, make every effort to ensure that application state doesn’t span multiple requests of your service(s).

3. Cache

A cache is temporary memory storage. RESTful services afford the opportunity to make some services cacheable in the client memory so that fewer calls are made to the server as the stateless nature of the service ensures that a lot of data is communicated between the client and server. However, this becomes an issue when data becomes stale and such information is still returned to the client.

4. Uniform Interface

Information is communicated in a standardized and uniform manner. The mode of action expected from a server by a client is usually defined in a uniform mode and as such; different applications cannot define extra action types to the server. Such action types like getting information from the server, updating information and creating or deleting information on the server are done uniformly.

Principles of Uniform Interface

Resource-Based

Individual resources are identified in requests using URIs as resource identifiers. The resources themselves are conceptually separate from the representations that are returned to the client. For example, the server does not send its database, but rather, some HTML, XML or JSON that represents some database records expressed, for instance, in Finnish and encoded in UTF-8, depending on the details of the request and the server implementation.

Manipulation of Resources Through Representations

When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource on the server, provided it has permission to do so.

Self-descriptive Messages

Each message includes enough information to describe how to process the message. For example, which parser to invoke may be specified by an Internet media type (previously known as a MIME type). Responses also explicitly indicate their cache-ability.

Hypermedia as the Engine of Application State (HATEOAS)

Clients deliver state via body contents, query-string parameters, request headers and the requested URI (the resource name). Services deliver state to clients via body content, response codes, and response headers. This is technically referred-to as hypermedia (or hyperlinks within hypertext).

Aside from the description above, HATEOS also means that, where necessary, links are contained in the returned body (or headers) to supply the URI for retrieval of the object itself or related objects. We’ll talk about this in more detail later.

The uniform interface that any REST services must provide is fundamental to its design.

5. Layered System

This allows that the RESTful services are composed of different layers where the different layers act more like independent sections in the transmission of data from the client to the server and vice versa. Different layers can, in turn, see different forms of data and can work directly on only that piece of information. This allows for speed in some case but sometimes can be a cause for latency.

6. Code on Demand

Servers are able to temporarily extend or customize the functionality of a client by transferring logic to it that it can execute. Examples of this may include compiled components such as Java applets and client-side scripts such as JavaScript.

Complying with these constraints, and thus conforming to the REST architectural style, will enable any kind of distributed hypermedia system to have desirable emergent properties, such as performance, scalability, simplicity, modifiability, visibility, portability and reliability.

NOTE: The only optional constraint of REST architecture is code on demand. If a service violates any other constraint, it cannot strictly be referred to as RESTful.