A Brief Overview of REST
Representational State Transfer (REST) is an architectural style consisting of a coordinated set of architectural constraints
applied to components, connectors, and data elements, within a distributed hypermedia system. It was formalised by
Roy Fielding and used throughout the design of HTTP/1.1 and Uniform Resource Identifiers (URI) standards to verify the
designs would meet the needs of the World Wide Web.
Designs aligning with REST exhibit the following properties, all of which are necessary for internet scale:
- Performance, both user perceived and network efficiency.
- Modifiability, including evolvability, extensibility, customizability, configurability, and reusability
The five interaction constraints necessary for REST are:
- Client-Server - A client component, desiring that a service be performed, sends a request to the server via a connector.
The server either rejects or performs the request and sends a response back to the client.
- Stateless - each request from client to server must contain all of the information necessary to understand the request.
- Cache - data within a response to a request must be implicitly or explicitly labeled as cacheable or non-cacheable,
allowing the client the right to reuse that data later for equivalent requests.
- Uniform Interface - consistent, generalised component interfaces allowing simplification of interaction.
- Layered System - components cannot see beyond the immediate layer with which they are interacting.
The Uniform Interface constraint is the distinguishing feature of REST, giving rise to four interface constraints:
- Identification of Resources - choice of a resource identifier that best fits the nature of the concept being identified.
- Manipulation of Resources through Representations - perform actions using a representation to capture state.
- Self-Descriptive Messages - messages are stateless and use standard methods and media types for semantics.
- Hypermedia as the engine of application state (HATEOS) - hypermedia controls are the driving force behind changes in
application state, such as clients responsible for state transitions and messages describing available transitions.
RESTful Web APIs
RESTful Web APIs follow the architectural principles of REST, utilising HTTP, URI and Media Types.
HTTP provides for the majority of the interaction constraints, the following list maps the interface constraints:
- Addressable resources - URIs are used to identify a resource. Even if the resource state changes, the URI stays the
same (although the client could be redirected to the new location).
- Self-Descriptive Messages - Each request stands alone, making use of media types to describe the representation and
semantics. The use of HTTP headers is significant here, especially Content-Type, Accepts, Link, and Cache-Control.
- Manipulation of Resources through Representations - Clients and Servers manipulate resources using HTTP methods to
describe how a resource should be manipulated, e.g. GET, POST, PUT, DELETE, along with representations of the resource.
The use of these methods is determined by the media type.
- HATEOAS - Principally the use of specific media types and links (i.e. URIs) in the representations to drive usage of the data.
The following resources provide further reading: