REST, short for representational state transfer, is a type of software architecture that was designed to ensure interoperability between different Internet computer systems. REST works by putting in place very strict constraints for the development of web services. Services that conform to the REST architecture can more easily communicate with one another.
RESTful services can request and edit text version of a web resource via a predefined set of operations that are uniform – and stateless. REST is just one type of architecture – SOAP web services is another example, and each of these architectures will have their own specific rules and operations.
The roots of REST
The original definition of a web resources was basically a document or a file that can be accessed using its URL. However as the web became more complex the term “web resource” has been expanded. Today, a web resource is essentially anything that can be found, given a name, reached or manipulated on the web.
When a RESTful web services requests a resource via it’s URI it will get a response that contains a “payload”. This payload is formatted in one of a number of set formats ranging from HTML and XML through to JSON. A response to a RESTful request can also state that something about the resource has changed, while it can also deliver hypertext links across to resources that are related to the requested resource – or indeed entire collections. When using HTTP (which is usually the method of choice) the developer has access to a range of operations including POST, GET, HEAD and even DELETE and TRACE.
REST developers make use of standard operations alongside a stateless protocol. The resulting RESTful system is more reliable, operates faster and also gives developers the option to re-use REST components. These components can be updated or managed on-the-go, doing so does not affect the entire underlying system – you can change RESTful system components while the system is running.
Roy Fielding developed REST in 2000 as part of his doctorate. His dissertation referred to REST principles in the context of the HTTP object model which dates from 1994. These were used when developing HTTP 1.1., and also while developing the standards around URI – the uniform resource identifier.
Why the name REST?
As you can imagine, REST as a term was used on purpose, it was supposed to make developers reflect on how web applications should behave when they are properly designed. Such an app should act as part of a network of web resources (also called a virtual “state-machine”). Within this network the user is able to step through their app by picking resource identifiers (a specific page or URL) and by then applying a HTTP operation such as POST. These operations are also called the “applicable” state transitions. The representation of the resource is then sent to the end user – this is the next application “state”.
The 2000 PhD dissertation, and what Fielding said
Roy Fielding, a student a the University of California at Irvine, did a PHD dissertation in 2000 which was called “Architectural Styles and the Design of Network-based Software Architectures”. While his PHD dissertation was published in 2000 he has in fact been working on REST for a number of years, he was arguably working on REST in parallel with HTTP 1.1 – HTTP 1.1. was being developed between 1996 and 1999 and was of course based on the HTTP 1.0 design of 1996.
In 2009, when looking back at how REST was developed, Fielding said the he was involved in the HTTP standardization process, and he was often asked to defend many of the choices made when designing how the Web works. Fielding outlined how challenging it was to do that given the fact that anyone could submit a suggestion on how the Web should work, and given that the Web was becoming absolutely central to an industry that was growing at breakneck pace.
Fielding says that at the time he had over five hundred developers commenting on the develop of the Web. Many of these engineers were highly experienced. It was part of Fielding’s job to explain all of the Web’s concepts from the ground up. Fielding says that the process of doing this helped him to settle down on some important principles. It also helped outline the constraints and properties that are now part of the REST architecture.
What are they key architectural principles of the REST architecture?
We explained earlier how REST works in a large part due to the constraints it places on web architecture. These constraints affect web architecture in these ways:
- By placing requirements on how quickly component interactions are performed – a key determinant in the way users perceive network performance, and a key factor in overall network efficiency.
- By enforcing scalability – in other words, so that large numbers of components are supported, alongside interactions between these components.
- Demanding a simple, uniform interface
- Ensuring that components can be easily modified when user requirements change, even while the app is running
- Making sure that the communication between service agents and components are totally visible
- Ensuring that components are portable as the code behind components can be moved with data intact
- Finally, REST demands that the entire system is resilient, no single connector or component failure should result in the entire system collapsing
It’s worth noting that Fielding has some specific comments around the scalability aspect of the REST architecture. Fielding referred to a unique characteristic of REST: the separation of concerns, assuring that components serve distinct purposes. This fact makes it easier to implement components, makes connectors simpler while also making it easier to tune applications for improved performance. Overall, server components become more scalable. Because system constraints are layered under REST it means that any intermediary such as a firewall or a gateway can be added into the application without the need to change the way components interface with one another. These intermediaries can therefore easily assist in the translation of communications – or by improving performance, Fielding pointed to caches that are large-scale and shared, for example.
Fielding said that, overall, REST makes intermediate processing easier. It does this by making sure that the messages sent by REST are self-descriptive. REST also ensure that interactions are stateless in between each request, while Fielding also pointed to the fact that REST imposes standard methods and standard media types when exchanging information. REST responses are also cache friendly.
The architectural constraints used by REST
Looking beyond architectural principles, it’s important to understand the constraints that define which systems quality as a RESTful system. There are six, and they are designed to limit the way servers respond to and process client requests. By imposing these limits, the system gains positive characteristics. Such a system performs faster and is simplified – it’s more scalable and also portable. At the same time a RESTful system is easier to modify while also being more visible. Overall, a RESTful system is more reliable too – thanks to the formal REST constraints:
Architecture based on a client-server approach
We touched on this point before: the separation of concerns. For example, with this approach the user interface tasks (or “concerns”) will be kept separate from the data storage tasks (“concerns”). In doing so the user interface is more portable and can be carried across to a different platform.
At the same time the system is also more scalable as the server components are simplified. In the context of the web, it’s worth noting that this separation means that distinct web components can grow and evolve on their own. It supports operations at inter-scale, a requirement where there are multiple organizational domains.
REST is stateless
In an important constraint, no client context may be stored on a server between client-server communications requests. The entire request must contain all the information needed to fully answer the request, and the client itself holds the session state. However, the session state can be transferred to, say, a database so that the state persists for a period of time. This can enable authentication for example.
Once the client is ready to transition to the next state it can start sending a request. Clients are in transition when there are no requests that have not been answered. When a client wants to start another state transition it can make use of the links which are contained in the representation of application states.
Content can be cached
When looking at RESTful architecture, both clients and tools that work as an intermediary are able to cache the responses to requests. However, every response must classify itself as either non-cacheable, or that it is OK to cache – this is to make sure that data that is not appropriate for a cache, or data that is stale, is not cached. Thanks to caching there are fewer interactions between client and server which means that an app performance better, and that apps are more scalable.
Layered architecture
Clients usually cannot tell whether an established connection contains an intermediary, or whether that connection is made directly with the server. For example, where load balancers or proxies are acting as intermediaries these won’t cause any issues with communications. Nor, under layered architecture, will using a proxy or load balancer require the need to edit code either on the client or on the server.
Servers that act as intermediaries can help to scale apps by working as a shared cache, or as a load balancer. Security is another benefit of the layered approach as a security layer can be added on top of a web app – and in doing so the security logic is running separately from the application logic. Developers can enforce security policies using this method. Also note that the layered approach means that a server can send a call to several servers in order to deliver a response to a client.
Code-on-demand
Finally, servers can hand code execution responsibilities to clients by sending code to a client – for example, a server can send java applets or JavaScript to a client so that the code is executed on the client side.
Uniform interfaces
Perhaps one of the most fundamental aspects of RESTful systems is the uniform interface, a way to decouple and simplify application architecture so that each component can develop and change on its own. There are four, further constraints involved in uniform interfaces:
- Requests must contain resource identifiers. As an example, a URI can be contained in a request to enable the resource to be identified. Note that, conceptually, resources are distinct from the results that are returned to a client. For example, no matter what the server’s own method of storing data is, the data sent in answer to a request could be sent as anything from XML to HTML or even JSON.
- Representations can manipulate resources. Clients might hold a representation of a specific resource – and this could contain metadata. This information is sufficient for the client to be able to change the resource, or to delete the resource.
- Messages are self-descriptive. Every message sent under a RESTful architecture will contain sufficient information for the recipient to be able to process the message – as an example, a message can use a media type to specify which parser should be used.
- HATEOAS. Short for “hypermedia as the engine of the application state”, this principle is just like a human having access to the home page of a specific website. The client should then have the option to make use of links provided by the server so that it can automatically understand which activities and resources it will require.
A few other points to note about REST
SOAP has specific standards that define SOAP web services. But in the case of RESTful applications there are is no officially-issued standards documentation. In a way you can see REST as a style of web architecture, rather than a specification or a protocol.
So, REST is not a standard but implementations that would objectively qualify as “RESTful” are very dependent on standards – indeed, they are standardised to a degree ,using XML, HTTP and JSON. Note that developers sometimes describe the APIs that they create as complying with REST architecture even if these APIs sometime skirt around the constraints imposed by RESTful architecture.