REST - Representational State Transfer

REST Architecture Style
Rest Architecture Style

Representational State Transfer

Year 1996

Berners-Lee writes that the "Web's major goal was to be a shared information space through which people and machines could communicate."

Year 2000

Hypermedia was chosen as the user interface because of its simplicity and generality. Hypermedia, an extension of the term called hypertext, is a non-linear medium of information that includes graphics, audio, video, plain text, and hyperlinks. A non-linear medium is any medium that can be navigated through random access.
The rapid growth of the Internet and the consequently deployed architecture had significant limitations in its support for extensibility, shared caching, and intermediaries, which made it difficult to develop ad-hoc solutions to the growing problems.
The challenge was to introduce a new set of functionality to an architecture that was already widely deployed, and how to ensure that its introduction does not adversely impact, or even destroy, the architectural properties that have enabled the Web to succeed.
The early Web architecture was based on solid principles--separation of concerns, simplicity, and generality--but lacked an architectural description and rationale. An architectural style could define the principles behind the Web architecture such that they were visible to future architects.

REST - Representational State Transfer

REST is an architectural style for distributed hypermedia systems, as it has been developed to represent the model for how the modern Web should work.
REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, the generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.


The following constraints are applied incrementally

Client Server

Results in the separation of two concerns and allow them to evolve independently.


In a client-server interaction, the communication must be stateless. The client should carry all the session state necessary for any interaction with the server and should not rely on the server storing any such context.
  • (+) Improves scalability 
  • (+) Simplifies server 
  • (-) Increased network latency


In order to improve network latency, responses should be labeled as cacheable or non-cacheable.
  • (+) Improves latency in some cases 
  • (-) Chances of client reading stale information

Uniform Interface

Uniform interface for interaction improves generality of a software and it decouples an implementation from its interface. It is an optimal decision with entire ‘Web’ in mind. It may be optimal for a system and may not be optimal for a particular application.
  • (+) Allows implementations to evolve independently 
  • (-) May not result in an optimal communication for some applications
Constraints for a uniform interface
  • Identification of resources 
  • Manipulation of resources through representations 
  • Self-descriptive messages 
  • Hypermedia as the engine of application state (HATEOAS)

Layered System

Hierarchical layers, where a component of a layer cannot see anything beyond its immediate layer. 
  • (+) This allows underlying layers to evolve independently 
  • (-) Increased latency

Code on Demand

REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This is an optional constraint.
  • (+) Simplifies client 
  • (+) Improves extensibility 
  • (-) Reduces Visibility 

Architectural Elements

Data Elements

  • Resource - A conceptual target of a hypertext reference. Any information that can be named is a resource. 
  • Resource Identifier - URL, URN 
  • Representation - HTML, JSON, XML, JPEG etc. Decoupling of a resource’s internal structure from its representation keeps clients unchanged whenever a resource’s internal representation changes. 
  • Representation Metadata - Media type, Last modified time 
  • Resource Metadata - Source link 
  • Control Data - Cache-Control


  • Client - Browser Libraries 
  • Server - Web Server API 
  • Cache - Browser Cache, CDN 
  • Resolver - DNS 
  • Tunnel - HTTP


  • Origin Server - Web Servers 
  • Gateway - Reverse Proxies 
  • Proxy - Proxy Server 
  • User Agent - Browser

For detailed reading please read the original 'Paper' presented by Roy Thomas Fielding


  1. This comment has been removed by a blog administrator.

  2. Good Blog, well descrided, Thanks for sharing this information.
    Big Data and Hadoop Online Training

  3. Big data is a term that describes the large volume of data – both structured and unstructured – that inundates a business on a day-to-day basis. big data projects for students But it’s not the amount of data that’s important. Project Center in Chennai It’s what organizations do with the data that matters. Big data can be analyzed for insights that lead to better decisions and strategic business moves.

    Spring Framework has already made serious inroads as an integrated technology stack for building user-facing applications. Corporate TRaining Spring Framework the authors explore the idea of using Java in Big Data platforms.
    Specifically, Spring Framework provides various tasks are geared around preparing data for further analysis and visualization. Spring Training in Chennai

    The Angular Training covers a wide range of topics including Components, Angular Directives, Angular Services, Pipes, security fundamentals, Routing, and Angular programmability. The new Angular TRaining will lay the foundation you need to specialise in Single Page Application developer. Angular Training


Post a Comment

Popular posts from this blog

Apache Hadoop Ecosystem

Software Architect and Software Architecture