REST (Rep­re­sen­ta­tion­al State Transfer)

The World Wide Web consists of more com­po­nents 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 ap­pli­ca­tions by providing a cor­re­spond­ing web service.

The social media network, Twitter, offers a good example for this; thanks to its cor­re­spond­ing web services, any ap­pli­ca­tion is able to read out or write tweets on behalf of a user.

There are various tech­niques to implement such web services: remote procedure calls (RPC), the network protocol, SOAP, or the pro­gram­ming paradigm, Rep­re­sen­ta­tion­al State Transfer (REST).

The term, ‘Rep­re­sen­ta­tion­al State Transfer’, comes from a dis­ser­ta­tion published by Roy Fielding, one of the main de­vel­op­ers of many different web standards. In abstract form, the computer scientist describes the un­der­ly­ing ar­chi­tec­ture of the World Wide Web (HTTP protocol, HTML and XML, parser, web and ap­pli­ca­tion servers, etc.). Generally speaking, REST’s ar­chi­tec­ture does not depend on any specific protocols. At the center of this concept lie resources, which, according to Fielding, must meet the following re­quire­ments:

• Ad­dress­abil­i­ty: each resource, e.g. an order, a product, or an article, must be able to be iden­ti­fied through a unique resource iden­ti­fi­er (URI).

• Unified in­ter­faces: every resource must be easily and uniformly ac­ces­si­ble 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 ap­plic­a­ble: A server provides a service that’s able to be requested by clients when needed.

• State­less­ness: com­mu­ni­ca­tion between servers and clients is stateless. This means that all exchanged messages contain all the in­for­ma­tion required for un­der­stand­ing them. The server doesn’t save any ad­di­tion­al in­for­ma­tion between any two messages in the form of sessions. And given that incoming requests can be re­dis­trib­uted with the help of a load balancing scheme, state­less­ness makes REST services very easy to scale up.

• Different rep­re­sen­ta­tions 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.

• Hy­per­me­dia: resources are made available via hy­per­me­dia, e.g. in the form of ‘href’ and ‘src’ at­trib­ut­es in HTML documents. They can also be provided for defined in­ter­faces of JSON or XML. Con­se­quent­ly, a REST-API’s client navigates according to the ‘hy­per­me­dia as the engine of ap­pli­ca­tion state’ (HATEOAS) method ex­clu­sive­ly via URLs that have been provided by the server; these don’t require any ad­di­tion­al in­for­ma­tion about the interface.

The strict standards of REST’s ar­chi­tec­ture enable services to be developed that com­mu­ni­cate via a common protocol (HTTP), are well struc­tured, 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. Al­ter­na­tive­ly, the stateless Hypertext Transfer Protocol is also rel­a­tive­ly simply struc­tured. 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 im­ple­ment­ing ad­di­tion­al 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 de­vel­op­ing a REST service via HTTP, which suggests that the ar­chi­tec­ture has been designed only for simple data man­age­ment tasks. What’s more, the principle of REST resources’ state­less­ness also appears to sig­nif­i­cant­ly limit the ar­chi­tec­ture’s ca­pa­bil­i­ties. 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 demon­strate.

• Web services with trans­ac­tions: Trans­ac­tion managers are essential for realizing web services with trans­ac­tions. Due to their state­less­ness, resources are always saved without ad­di­tion­al in­for­ma­tion between requests. This means that a REST im­ple­men­ta­tion is re­strict­ed into two different options:

• Asyn­chro­nous 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 mech­a­nisms for this task, the only option available to server providers is to manage pro­cess­ing the requests them­selves and forward these on user requests.   

• Web services with extensive in­ter­op­er­abil­i­ty: REST services are char­ac­ter­ized by their flex­i­bil­i­ty. This flex­i­bil­i­ty is brought on by the fact that one basic protocol is focused on and that mobile clients es­pe­cial­ly benefit from the limited demands of REST’s ar­chi­tec­ture. The fact that these resources are easily available also makes it easy for them to be found by search engines without any as­sis­tance.

The REST framework offers an excellent means for drafting and im­ple­ment­ing 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 ef­fort­less­ly work with the REST interface without need for any ad­di­tion­al im­ple­men­ta­tions. The results are web services that feature a sub­stan­tial degree of:

• Platform in­de­pen­dence,

• scal­a­bil­i­ty,

• per­for­mance,

• in­ter­op­er­abil­i­ty,

• and flex­i­bil­i­ty.

Using this ar­chi­tec­ture does require cor­re­spond­ing know-how. Es­pe­cial­ly managing the in­ter­ac­tion between the in­di­vid­ual, stateless resources is both complex and difficult to achieve. Those who’ve already worked with al­ter­na­tives, like the protocol SOAP, will surely be left pondering over the unusual ap­proach­es this ar­chi­tec­ture employs; however, REST proves to be a service that’s much more useful.