Skip to main content

REST (Representational State Transfer)

REST is an architectural style, specifically for Network based application. Roy Fielding introduced it as part of his PHD dissertation. This blog is my assimilation of his thesis and I am most likely miles off of what it means, even worse I might be completely wrong. If you're reading this then please consider reading the original dissertation.

Fielding defines REST as an architectural style derived by composing pre-existing architectural style/constraints. Each pre-existing architectural style induces a set of architectural attributes.

While working on standardizing HTTP/1.1 & URI scheme, he attributed the architectural decisions to be based off of REST.

Architectural Styles(Constraints) and Architectural properties​

Http/1.1 being a protocol has to be generic enough to support a vast category of web applications but at the same time it should limit customization in order to be interoperable between implementations of different vendors.

To arrive at the philosophy of Http, the author starts off by applying numerous Architectural Styles one by one. Architectural style is also referred to as Architectural Constraint, which sounds a bit counter intuitive as if it limits the behavior of a system. It actually signifies the constraints that must be applied to uphold the Architectural style. An Architectural style induces a set of Architectural properties.

For example: Client Server Architectural style induces Scalability, Simplicity and Evolvability. In a Client Server Architecture the User Interface component is separated out into the client allowing clients and servers to evolve independently. To drive the point home:

  • Architectural Style: Client Server
  • Applies: Constraint of separating UI component from Server
  • Inducing: Scalability, Simplicity and Evolvability

Rest Architectural Style​

Rest is combination of following architectural styles:

  1. Client-Server: Separation of concern allows clients and servers to be independently scalable.
  2. Stateless: A request can be observed in isolation
  3. Cache: Ability to reuse response in future inducing performance
  4. Layered: A layer only needs to know about its immediate neighbors
  5. Uniform Interface: Common generic interface of communication among all layers, causing individual request to be self-descriptive
  6. Code-On-Demand(Optional): Code shared to the receiving component

Together these style induce a Architectural properties. Here is the matrix diagram.

REST Architectural elements​

Rest, like any other architectural style can be defined using boxes, lines and the information flowing between them

  • Data Elements: Information
  • Connectors: Interface of communication
  • Components: Originator, terminal or an intermediary

A good analogy would be a tap connected to an overhead tank. The tap and tank are the components, plumbing pipe is the connector and the water flowing between them is Data Element.

Rest ElementsRest Elements

Data Elements​

  • resource: The core concept, anything that can be named is a resource, such as Person or a temporally varying information such as Today's Weather
  • resource identifier URL, URN, unique id of resource
  • representation HTML document, JPEG image
  • representation metadata media type, last-modified time of resource representation
  • resource metadata source link, alternates, vary
  • control data if-modified-since, cache-control

Connectors​

  • client Requestor
  • server Responder
  • cache Intermediary
  • ...

Components​

  • origin server Resource owner
  • gateway Reverse proxy - intermediary
  • proxy Proxy - intermediary
  • user agent Resource user

RESTful HTTP API​

Idea is to model your application as a collection of resources and their manipulation through Http APIs

An application can be said to be RESTful if

HTTP Methods​

🚧 Work in Progress...