[Re]presentational [S]tate [T]ransfer

Introduction

The acronym REST stands for Representational State Transfer and describes a programming paradigm for distributed systems. The The focus of REST is on machine-to-machine Communication.

The paradigm describes stateless communication, so it can REST can be implemented with any stateless protocol, the most common HTTP¹ is used to implement REST. The designation Representational State Transfer is intended to be the transition from a state from one application to the next state.

Story

REST was first used in the dissertation "Architectural Styles and the Design of network-based software Architectures" by Roy Thomas Fielding 2000 describes what lies behind the paradigm However, the basic principle has existed since the introduction of the WWW² by Tim Berners-Lee 1991. Fielding writes about this in his dedication:

DEDICATION

[...]
And also to
Tim Berners-Lee,
for making the World Wide Web an open, collaborative project.

So REST is already an old paradigm, but only in the last few years Has been used in many applications since around 2014. The reason This is not known here, but here is an attempt to explain it.

Applications were created using the Representational State paradigm Transfer implemented, but the paradigm was implemented incorrectly and therefore did not lead to the desired result. Therefore, REST rejected again and other paradigms were used. These then led to the desired result and displaced REST be a little forgotten. Which makes REST as a paradigm Approximately 2014, it found its way into modern applications cannot understand. But today there is hardly an application that has one Interface offers this via non-RESTful resources makes.

REST - principles

In his dissertation, Fielding calls for a total of six principles the REST paradigm, these will be discussed in the following sections explained.
In the explanations I will refer to HTTP as the paradigm most commonly used with and from this protocol was created.

Client-Server

The first principle mentioned for REST is a (classic) Client-server environment required.

Statelessness

As mentioned in the introduction, the paradigm is representational State transfer stateless. Statelessness means that every Message exchanged between client and server all Information includes each other to interpret the Message needed. So there is no information about the condition saved between two messages.

Caching

HTTP caching should be used, so resources are stored have not changed and stored in a cache. This reduces the Burden of communication because a resource is not always new must be requested.

Consistent interfaces

The principle of unified interface can be divided into four properties be divided. The unified interface is the biggest Differentiating feature from other paradigms, see also Section “Distinctions from other communication mechanisms.

Resource addressability

Resources are information identified by a URI³. were. A RESTful service has a unique address URL⁴ through which the access paths to this service are standardized become.

Representation for changing resources

A RESTful server can have one depending on the client’s requirements Deliver resources in different representations. Can do that but also different formats such as HTML, JSON or XML different languages or the documentation of the resource. The Change of a resource should only occur via a representation This means when we reach a resource in JSON format If you can and would like to change it, then we will send it along in this case the HTTP verb PUT a representation of the changed resource in JSON format.

Self-describing messages

REST-compliant messages should be self-describing, i.e. all of them Contain information that is needed. Furthermore, this means that standard methods are used, at this point they are Called HTTP verbs, these are described in the “Implementation of the REST paradigm” section.

Hypermedia as the Engine of Application State (HATEOAS)

According to Fielding, this is probably the most important property of the Representational State Transfers, HATEOAS is described in the section “Hypermedia as the Engine of Application State”.

Multi-layer systems

The principle of multi-layering is also used by Fielding for REST Paradigm required. Multi-layer systems enable the user just offer an interface, the layers behind it remain the same Hidden from user. This means the entire architecture can be simplified and it offers interchangeability.

As an example: We have a web application that consists of a frontend and consists of a backend, both were built with different technologies implemented, they communicate via REST interfaces. Would you like it now? Changing the technology in the backend is not a problem as the new one Technology just needs to provide the same interfaces.

Code on Demand

The Code on Demand principle is the only principle that fielding only optionally requires. Code on Demand means something like code on demand.

As an example: A classic web application runs JavaScript code only off when a specific resource is retrieved.

Hypermedia as the Engine of Application State (HATEOAS)

First, a simple definition of hypermedia:

Hypermedia are electronic documents in the form of hypertext that Connections (hyperlinks) to other media, such as graphics, sound or Video included. They enable multimedia Information presentations and access through links.

Hypermedia on e-teaching.org

Hypermedia as the Engine of Application State is a design principle of REST architectures and means that the client exclusively navigated via the URLs provided by the server. Looking at it HATEOS abstractly, one finds that it is a finite automaton represents. The state changes of the machine take place here the URLs provided.

Implementation of the REST paradigm

The HTTP verbs

Below are the so-called HTTP verbs or HTTP methods presented and their function within a REST API.

GET

By calling a resource using the GET method Information returned without side effects occurring. I.e. no changes are made to the state on the server, therefore GET also referred to as secure.

POST

Adds a new record. Is a resource using POST If the same data is called multiple times, several will be used new records added.

PUT

Used to update a record, a Resource, accessed multiple times with the same data, changes the state of the data record only when called up for the first time. The PUT Method is idempotent.

PATCH

A part of a specified resource is changed, unlike PUT Side effects are allowed here. This method is optional and will not needed for CRUD⁵ operations.

DELETE

If a resource is called using the DELETE method, the associated data record deleted. This method is also idempotent.

HEAD

HEAD is used to request metadata about a resource.

OPTIONS

This method can be used to check which method is used for a resource are available.

CONNECT

This method is used to route requests through a TCP tunnel.

TRACE

The TRACE method returns requests as received by the server receives.

Security in the REST paradigm

In short, security mechanisms are not in the REST paradigm described.

To ensure security, the protocol used must be over have security mechanisms. This is for HTTP with Secure type, so HTTPS. This is the encryption of the communication guaranteed, but authentication is not.

To establish authentication in applications running REST Paradigm implemented are so-called token-based Authentication method used. Like for example:

• JSON Web Token (JWT)

• OAuth

• OpenID

And other procedures based on authentication using tokens.

Differentiation from other communication mechanisms

The Representational State Transfer paradigm is primarily accurate that, a paradigm. There is no standard set by a committee is specified and adopted. There are, of course, for individuals Programming languages reference implementations with which to create REST APIs can design and implement. But REST as such is a Paradigm, without strict guidelines.

So REST can be implemented with different mechanisms and Applications are not always implemented completely RESTful, more on that in the following.

What sets REST apart from other communication mechanisms is this low overhead⁶ of metadata that has to be exchanged, because REST pays attention to a wide use of methods.\ REST does not require machine-readable documentation, such as WSDL. Documentation is human-readable and with good design the API is partly superfluous because there are clear URLs which are in Combination with the appropriate HTTP method reveals the context let.

Richardson-Reifegradmodell

As mentioned in the previous chapter, there is no standard the REST defines. Leonard Richardson developed a standard with which can be defined how strict or how mature a service is according to REST is. The Richardson Maturity Model (RMM) or translates that Richardson maturity model is divided into four different ones Levels starting at level 0.\ The stages build on each other, with stage 0 being the so-called Swamp of POX⁷ is and level 3 is a RESTful service.

Level 0

Only a single URI and HTTP method is used and XML-RPC or SOAP serve as the protocol

Stage 1

Multiple URIs and resources are used and still only a single method.

Stage 2

Multiple URIs, resources and HTTP methods are used.

Stage 3

The application is based on HATEOAS and uses multiple URIs, Resources, HTTP methods and HTTP status codes.

When developing a REST API the Richardson maturity model should be used always be taken into account as it provides guidance represents design decisions.

Using the maturity model, you can classify a service looks at its REST implementation. So how much did the paradigm become followed or implemented, how “ready” the application is.

Three terms have been established in the developer community:

Not RESTful

REST has not been implemented, individual parts of the paradigm are used. Level 0 - Level 1

Not fully RESTful

REST has been largely implemented, but the most important one according to Fielding Property HATEOAS is still missing. Stage 2

Completely RESTful

The application has implemented all of Fielding’s requirements. Stage 3

Conclusion

The representational state transfer paradigm is ideal to make architectures scalable. But also about maintainability, Extensibility and flexibility in an architecture to a greatest extent possible point.

New applications and architectures should always consider REST pull, REST is simply “good form” for web services.

List of abbreviations