REST Architecture Style

‘REST’ is the latest buzzword in modern web. Almost all the big companies have created and published REST APIs such as Gmail API, Facebook API, Amazon web services API and are used by developers world wide. So in this tutorial let us see,

What is REST ?

REST stands for “Representational state transfer”. It is an Architectural style which applies a set of constraints on the system components to acheive a scalable and long-lasting web based system.
As REST was developed keeping World Wide Web (WWW) in mind, it became very much suitable for applications having server or client components at such large scale and systems that need immense scalability, durability and longevity.

Quick History:

The term REST was coined by Roy Thomas Fielding in his PhD dissertation “Architectural Styles and the Design of Network-based Software Architectures” in the year 2000. This architectural style is not new and has been used since 1994 to guide the design and development of modern web. REST was originally referred to as “HTTP Object Model”. Later the name was changed to Representational state transfer(REST)to evoke an image of how a system based on this Architecture style will work. In 1994 and 1995, when Roy Thomas Fielding was involved in authoring the specifications for HTTP/1.0 and initial HTTP/1.1 proposal, the team faced many challenges due to the existence of diverse architecture styles and various different intermediate components in World Wide Web (WWW). For all these components to work in tandem and work in harmony Roy Thomas Fielding felt the need of certain constraints to be applied on the system components. Thus the first edition of REST was born. It was developed during this time period by listing down the desired characteristics of modern web (or future web) and how to achieve those desired characteristics (that is, by applying proper constraints).
REST was then applied while authoring subsequent HTTP and URI specifications for World Wide Web and also developed iteratively side by side during the
following years. Finally Roy Thomas Fielding submitted this architecture style as part of his PhD dissertation in 2000.

In June 2014 new RFCs for HTTP 1.1 were published by IETF (Internet Engineering Task Force). Roy Thomas Fielding and Julian Reschke served as editors for this project.
As part of this more details have been added to HTTP specification such that it gives the developers and architects world wide a more clear understanding of HTTP specification in REST terms such as resources and representations.
Here however an important point to keep in mind is REST Architectural style is NOT tied to any specific protocol.

What are the desired characteristics or benefits that REST Architecture style induces into the system ?

  1. Separation of Concerns – By separating the front-end(client) concerns from the back-end(server) concerns the client and server can evolve independently.
  2. Visibility – The system should be able to be monitored easily.
  3. Reliability – The system should be able to work consistently and be able to recover easily from partial failures.
  4. Scalability – The system should be able to expand easily based on future growth.
  5. Efficiency – The performance of the system should be improved.
  6. Simplicity – The overall system architecture should be simple.
  7. Portability – The client or server should be portable across different platforms.
  8. Cacheability – Whenever needed the responses should be able to be cached to avoid unnecessary network calls.
  9. Longevity & Durability – The system has to withstand minor changes to its components and should be able to exist for longer period of time (say in decades) without much architectural change.

What are the six constraints that makeup the REST Architecture style ?

REST architecture style applies a set a constraints on system components to achieve the desired characters. The six constraints that make the REST Architecture are provided below; of which the sixth one “Code-On-Demand” is an optional constraint.

  1. Client-Server
  2. Stateless
  3. Cache
  4. Uniform Interface (Central feature of REST)
    Identification of Resources.
    Manipulation of Resources through Representations.
    Self Descriptive messages.
    Hypermedia as the engine of application state.
  5. Layered System
  6. Code-On-Demand (Optional)

As we can see, all these constraints are not new and some of them already exists in several other Architecture styles. If all of these constraints are applied together on a distributed hypermedia system it makeup the REST Architecture style.

Note: Uniform Interface constraint is the central feature of REST and distinguishes REST from other Architecture styles. This constraint can be achieved by following four child constraints.

1. Identification of Resources.
2. Manipulation of Resources through Representations.
3. Self Descriptive messages.
4. Hypermedia as the engine of application state.

A brief definition of these constraints is provided below and we think is sufficient for this tutorial.
For more details please visit Roy Thomas Fielding’s doctoral dissertation at: “”

1. Client-Server: The system components are divided into clients and servers. The client initiates communication by making a request and server listens for connections and responds to requests. All the User Interface concerns reside at the Client side and all the data concerns residing at the server side. There can be multiple clients and servers in a system. The same component can act as a client as well as a server.
This induces Separation of Concerns which in turn induces portability and scalability to the system. The Client initiates communication by making a request and server listens for connections and responds to requests.

2. Stateless: The server should not maintain state information and it should be the responsibility of the client to handle the user sessions properly. This makes the server simple and scalable; increases reliability and visibility of the system.

3. Cache: The responses from the server should be labelled as cacheable or non-cacheable so that non changing contents like news paper articles of a particular day can be cached at
the client side or by intermediaries to avoid unnecessary network calls to the server. This improves performance and efficiency of the system.

4. Uniform Interface: The client and server communication should be via a uniform interface. To achieve uniform interface the following constraints should be applied.

         a. Identification of Resources:  In REST Architecture style, the target information or data on which a client is interested in are called resources. Whatever that be named are resources in REST. For example a newspaper article, a tea cup, an employee, a stock price, an algorithm is a resource.
These resources should be identifiable by some identifiers (for example: URIs (Uniform Resource Identifiers) such as:,
In REST, the authors (Server side stake holders) are responsible for choosing a URI that best fits the nature of the concept identified and it should not be changed often.

         b. Manipulation of Resources through Representations: The server Resources that are identified by identifiers (such as URIs) will be manipulated by client via some form of Representation.
For example the Representations can be in the form of Plain Text, HTML, XML, JSON, Images etc. If we consider a book as a resource in a web system, it can be manipulated(read) by representations(Page1, Page2) transferred from Server to the client and is invoked by client actions by navigating through hyperlinks.

Representation = A Resource at a particular state (past or present) in a particular format (such as xml, json, html, text etc)

If we consider stock price of google as a resource, yesterday's stock price of google in JSON format is a representation of that resource. 

One important point to note here is, the resources will be manipulated by clients only through some form of representations and not directly. This way the resource will be hidden and prevent many security issues.

         c. Self Descriptive messages: The requests and response should contain all the necessary information for that transaction to complete. Basically the server should not depend on stored session details or any previous requests to understand and process the current request. All the details required to process the request should be available in that request. If some intermediaries want to cache a page or process that page, it will be possible only if the message is self descriptive.

         d. Hypermedia as the engine of application state: Hypermedia, is nothing but media with hyperlinks(in HTML parlance) or media which has details for the client to branch out/navigate to other sources if needed. The media can be any data be it text, json, video, audio or an image.
The state of the system should be driven only via hyperlinks (or just links in non HTML parlance). For example, when filling out a multipage form in online, it should be enough for the user to know only the first page URI of the form. After that any help or reference material provided to fill out the form and navigation till the completion and submission of the form should be driven by hyperlinks provided in the responses.

5. Layered System: The system should be able to have many intermediate layers such as proxies, gateways, firewalls, intermediate caches and servers however the client should know only about the immediate layer to which it interacts and not any layers beyond that. The intermediate layers within the system can perform any transformation of request or response before it reaches the actual destination. Legacy services can also be encapsulated within one of intermediate layers.

6. Code-On-Demand (Optional): This is an optional constraint in REST Architecture Style. This can reduce the client complexity by sending the code(such as Java applet) to the client from server whenever possible. The supplied code can do various operations for the client and the client doesn’t need to be coded for those operations. But some systems
doesn’t allow the transfer of code from server to the client across firewalls. Hence Code-On-Demand can be used wherever possible and is optional for REST Architecture style.

Why this Architecture style is named as “Representational State Transfer” ?

It is called “Representational State Transfer” because that is what the system does (or) that is how the system works, when following REST architecture style.
The State of the system is Transferred between client and server as Representations such as HTML, XML, JSON, JPEG etc.

Example 1: Consider an online tutorial which require users to take a test to mark completion of the tutorial.
1. When user starts learning the course the system enters say State #1. At this state the course contents are transferred from Server to Client as Representations and the Representations can be in any format such as XML, JSON, HTML etc.
2. When user reads the course materials and click “Start Test” the system enters State #2. During this state, the Test Contents are transferred from Server to Client as a Representation such as XML, JSON, HTML etc.
3. When user finishes the test, the system enters the next state say State #3. During this state the client posts the test results to the server as a Representation.

In this example the entry points for States #1, #2 and #3 are just logical and can be modified differently for better understandability.

Lets see HTTP as Uniform interface in the next page.

%d bloggers like this: