What is REST?
Representational State Transfer (REST) was first officially described by Roy Fielding in his 2000 dissertation “Architectural Styles and the Design of Network-Based Software Architectures”. Up until that point, there was no formal architectural model that described how the web worked and much of what was available was from the CERN library which was not intended to meet the scalability needs of mid 90’s web explosion. Through REST, Fielding parsed and collated best design practices, creating a blueprint for simplified, more scalable websites and services.
According to Fielding, REST describes “how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.” REST is an abstraction of the elements that make up the web and is derived by applying a series of six constraints: client-server relationship, statelessness, cache, uniform interface, layered system and code on demand.
The Client-Server Relationship: The separation of client and server allows for scalability by simplifying the jobs of both client and server. This separation of concerns also permits both components to evolve independently. Thus, servers can respond to requests efficiently, creating greater client mobility and server simplicity.
Statelessness: Each request sent to the server must be considered in isolation; furthermore, metadata needed to process the request must be included in the message. This process puts the responsibility of maintaining application state within the client-side and frees the server-side to be simpler and more easily scalable. Each request has all the metadata needed to understand how to process the message outside the context of previous communications. The stateless constraint, like the client-server constraint, provides greater scalability and simplicity.
Cache: Cache, a localized resource storage mechanism, can be located on either client or server and in both cases, it is used to improve performance. This is because caching can completely eliminate some client-server interactions and accessibility to resources on local systems reduces latency. By default, responses to retrieval requests are cacheable (though no other requests are cacheable by default). However, theses defaults can be overridden with control data that indicates cache-ability. Information about other components within a topology may be cached, which can further boost performance.
Uniform Interface: The uniform interface means that the interface between components is generalized. This allows decoupling of components and simplification of the architecture. For modern RESTful services this uniform interface means using the HTTP verbs GET, PUT, POST, and DELETE for most client-server interactions. To create uniformity, four additional constraints are applied to the interface: identification of resources, hypermedia as the engine of application state (HATEOAS), manipulation of resources through representations, and self-descriptive messages.
1. Identification of resources is the URI. URIs are meant to be general and point to concepts rather specific instances of concepts. They do this by generally remaining static though the resources they point to change over time. For example, the URI for http://www.cnn.com remains the same though the content of the site is constantly updated.
2. HATEOAS means that clients transition through various application states via the hypermedia, generally hyperlinks, found within the resource representations that have been delivered from the server.
3. Manipulation of resources through representations means that the client does not access the resource itself, but a representation of it. However, it is still able to modify the resource via the representation. Enough information about the resource must be provided to client through the resource representation for this to occur.
4. Self-descriptive messages are messages indicating that all the metadata needed to process a request is contained within the request. This helps to maintain statelessness of requests by omitting the need for message context.
Layered System: A layered system means that client server interaction is not affected by intermediary components, such as proxies and gateways, that may be in between the endpoints. These intermediaries can assist in performance enhancing by providing shared caches and be used to enforce security policies. A layered system increases performance and strengthens network security.
Code-On-Demand: This is an optional constraint but it allows for servers to enhance the functionality of the client by sending executable logic. This takes the form of JavaScript and its frameworks on the modern web; however, Java applets were also used in the past. Code-on-demand is in large part responsible for the versatile and dynamic modern web.
REST is both a description of how the web works and a blueprint for building well-designed web services and Application Programming Interfaces (APIs). RESTful APIs are services that allow users to access resource representations and manipulate the resources themselves via HTTP verbs, while changing the application’s state by navigating the URI hierarchy located within the resource representations.
An example of a RESTful API would be a weather API that allows other applications to pull some of its data. The requesting application (client) would send an HTTP GET request for the resource, the server would send back a representation of that resource in either JSON or XML and the client would parse out the data it needed from the representation. RESTful APIs allow user-friendly interfaces without sacrificing user control of resources.
A potential future use of the REST architecture is described by Khan et al. in an article titled “A Web of Things-Based Emerging Sensor Network Architecture for Smart Control Systems”. In the article, they detail a sensor network that collects data from smart appliances and routes the data to the web allowing users to interact with the appliances via a web interface. The web interface communicates with the appliances via HTTP thus allowing users to manipulate their appliance using RESTful HTTP verbs. They provide examples for each verb: a GET request could return the energy consumption of a home, a POST request could be used to switch off a lighter, a PUT method would be called upon whenever new appliance was added to the home, and a DELETE request used when an appliance was removed from a home. This system effectively turns home appliances into web resources.
In another article titled “ICT For Green — How Computers Can Help Us to Conserve Energy”, Mattern et al. discuss the eMeter System, which is a home energy feedback system that sends energy usage data from various power consuming sources to a mobile app. The architecture of the system is composed of three components: a smart electricity meter that logs the load of the devices on the residential power line, a gateway implemented in Java that manages the data by storing it in a SQL database and allowing access to JSON representations of the data via HTTP requests, and a mobile app that allows users to monitor their energy usage in real-time. The system follows REST principles by treating the data as resources with hierarchical URIs and relying on HTTP as a uniform interface between the mobile app and the gateway.
The common feature of these REST implementations is that they manage the complexity of large, distributed systems.
The central thesis of REST is that by placing constraints upon these systems, an architectural design emerges that meets the needs of those using the system while allowing “the forces that influence system behavior to flow naturally, in harmony with the system”.
