REST (Representational State Transfer)

The World Wide Web consists of more components than those exposed to the users when they access a website. Both human users and machines access data from web projects. In order for this to work, website operators need to make their website available to other applications by providing a corresponding web service.

The social media network, Twitter, offers a good example for this; thanks to its corresponding web services, any application is able to read out or write tweets on behalf of a user.

There are various techniques to implement such web services: remote procedure calls (RPC), the network protocol, SOAP, or the programming paradigm, Representational State Transfer (REST).

The term, ‘Representational State Transfer’, comes from a dissertation published by Roy Fielding, one of the main developers of many different web standards. In abstract form, the computer scientist describes the underlying architecture of the World Wide Web (HTTP protocol, HTML and XML, parser, web and application servers, etc.). Generally speaking, REST’s architecture does not depend on any specific protocols. At the center of this concept lie resources, which, according to Fielding, must meet the following requirements:

• Addressability: each resource, e.g. an order, a product, or an article, must be able to be identified through a unique resource identifier (URI).

• Unified interfaces: every resource must be easily and uniformly accessible with the help of standard methods. For example, through HTTP methods, like ‘GET’, ‘POST’, or ‘PUT’.

• Client-server structure: generally, the client-server principle is applicable: A server provides a service that’s able to be requested by clients when needed.

• Statelessness: communication between servers and clients is stateless. This means that all exchanged messages contain all the information required for understanding them. The server doesn’t save any additional information between any two messages in the form of sessions. And given that incoming requests can be redistributed with the help of a load balancing scheme, statelessness makes REST services very easy to scale up.

• Different representations of resources: every web resource may feature multiple display formats. Depending on what the client requests, these resources may need to be delivered in different languages or formats like HTML, JSON, or XML.

• Hypermedia: resources are made available via hypermedia, e.g. in the form of ‘href’ and ‘src’ attributes in HTML documents. They can also be provided for defined interfaces of JSON or XML. Consequently, a REST-API’s client navigates according to the ‘hypermedia as the engine of application state’ (HATEOAS) method exclusively via URLs that have been provided by the server; these don’t require any additional information about the interface.

The strict standards of REST’s architecture enable services to be developed that communicate via a common protocol (HTTP), are well structured, and are easy to integrate.

In order to implement a REST service, HTTP and its encrypted cousin, HTTPS, are primarily used. One reason for this is the protocols’ wide use, a fact that allows users to get by virtually any firewall. Alternatively, the stateless Hypertext Transfer Protocol is also relatively simply structured. The HTTP standard has a complete set of commands on offer, with which resources can be accessed:

This range of commands can be increased by implementing additional protocols. To this end, the WebDAV protocol is often used. This adds the methods COPY (copies resource), MOVE (moves resource), LOCK (locks resource), UNLOCK (unlocks resource), and MKCOL (creates directory).

Typically, standard methods like GET, POST, PUT, PATCH, and DELETE are used when developing a REST service via HTTP, which suggests that the architecture has been designed only for simple data management tasks. What’s more, the principle of REST resources’ statelessness also appears to significantly limit the architecture’s capabilities. By using the resources in the right way, however, the REST interface makes it possible to do more than simply add and retrieve data sets, as the following examples demonstrate.

• Web services with transactions: Transaction managers are essential for realising web services with transactions. Due to their statelessness, resources are always saved without additional information between requests. This means that a REST implementation is restricted into two different options:

• Asynchronous web services: for certain web services, it may be desired to have requests and answers decoupled from one another in terms of time. Given that HTTP doesn’t offer any mechanisms for this task, the only option available to server providers is to manage processing the requests themselves and forward these on user requests.   

• Web services with extensive interoperability: REST services are characterised by their flexibility. This flexibility is brought on by the fact that one basic protocol is focused on and that mobile clients especially benefit from the limited demands of REST’s architecture. The fact that these resources are easily available also makes it easy for them to be found by search engines without any assistance.

The REST framework offers an excellent means for drafting and implementing different kinds of web services. Thanks to the fact that the Hypertext Transfer Protocol is supported by virtually every device, both desktop as well as mobile clients are able to effortlessly work with the REST interface without need for any additional implementations. The results are web services that feature a substantial degree of:

• Platform independence,

• scalability,

• performance,

• interoperability,

• and flexibility.

Using this architecture does require corresponding know-how. Especially managing the interaction between the individual, stateless resources is both complex and difficult to achieve. Those who’ve already worked with alternatives, like the protocol SOAP, will surely be left pondering over the unusual approaches this architecture employs; however, REST proves to be a service that’s much more useful.