REST - The Abstract Web Architecture
REST is a pseudo-acronym for REpresentational State Transfer. The idea here is to have the transfer of data or state be representational of the kinds of messages that you want to use.
In his dissertation, Architectural Styles and the Design of Network-based Software Architectures, Fielding came up with six categories of constraints of the web, they are:
Client-Server
Layered system
Cache
Stateless
Code-on-demand
Uniform interface
Identification of resources
Manipulation of resources through representations
Self-descriptive messages
Hypermedia as the engine of application state (HATEOAS)
Let's go through each of them briefly.
Client-Server
Separation of concerns is the principle behind the client-server constraints. By separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components. Perhaps most significant to the Web, however, is that the separation allows the components to evolve independently, thus supporting the Internet-scale requirement of multiple organizational domains.
This essentially means that the client and the server should be separate and can both be deployed independently of each other.
Layered System
In order to further improve behavior for Internet-scale requirements, we add layered system constraints... [t]he layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot "see" beyond the immediate layer with which they are interacting. By restricting knowledge of the system to a single layer, we place a bound on the overall system complexity and promote substrate independence. Layers can be used to encapsulate legacy services and to protect new services from legacy clients, simplifying components by moving infrequently used functionality to a shared intermediary. Intermediaries can also be used to improve system scalability by enabling load balancing of services across multiple networks and processors.
This is a handful to digest, but what it essentially means is that the layered architecture allows us to sandwich in different layers in between the client and server. Examples of these layers might be a cache proxy layer, an API gateway layer, or even a load balancer.
Cache
Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable. If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests.
This constraint suggests that when a server sends a response to a client, it should indicate the response can be cached or not. A cache may exist anywhere along the network path between the client and server. For instance, inside an organization’s web server network, within specialized content delivery networks (CDNs), or inside a client itself.
Stateless
Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.
This means that the communication between the client and server should not maintain any sort of state.
Code-On-Demand (Optional)
The final addition to our constraint set for REST comes from the code-on-demand. REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented. Allowing features to be downloaded after deployment improves system extensibility.
The language here is quite old, but if you are a JavaScript developer then this is quite easy to understand. This just means that a server is able to provide executable code to the client. The most ubiquitous example is having including an app.js file in a script tag in your .html file.
Uniform Interface
The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components. By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. Implementations are decoupled from the services they provide, which encourages independent evolvability. The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs. The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.
The interactions between the Web’s components (clients, servers, and network-based intermediaries) all depend on the uniformity of their interfaces. These Web components communicate within the uniform interface’s four constraints, which Fielding identified as:
Identification of resources
Manipulation of resources through representations
Self-descriptive messages, and
Hypermedia as the engine of application state (HATEOAS)
There 4 interface constraints and can be can summarized in the following subsections.
Identification of resources
Identification of resources refers to the ability for one to address a unique resource via a unique identifier, such as a URI. For example, https://www.google.com, uniquely identifies the concept of a specific resource - a specific web page in this case.
Manipulation of resources through representations
Manipulation of resources through representations refers to the way in which the same exact resource can be represented to different clients in different ways. For example, a document might be represented as HTML to a web browser, and as JSON to an automated program. The client is also able to view the resource in different ways and formats without ever changing its identifier. For example, one can call a URI and 'Accept' it as application/json or application/xml.
Self-descriptive messages
Self-descriptive messages refer to the details within the request/response itself. Relating this to HTTP, this is where the headers comes into play along with its various types of metadata that can be sent with the request/response.
Hypermedia as the engine of application state (HATEOAS)
Probably one of the most confusing concepts that all web developers have struggle to understand. I will try to explain this in very simple terms. Resources themselves should have links in them. Imagine you are on a website and you are clicking on different links that take you to different web pages. HATEOAS refers to the links you see on the navigation bar, the home page button, the about page, the profiles of your friends, and the plethora of user-generated content that have their own unique URIs. The difference in this case is that there is no UI, but only representations that contain those links.
In the next section, we will look at how HTTP is in fact an implementation of the REST architecture.
Last updated
