The REST interface

As a teaser, let's take a look at one of the possible options, the REST interface. There is always talk of this interface, and today in particular, this solution is of major importance. It is therefore all the more important to understand it. So what do we mean by REST?

These interfaces were created especially for distributed systems, in particular for WebServices. Here, the transition from the current state to the next state is ensured by means of an interface, and this is done by transferring the data representing the next state.

The acronym "REST" is derived from this very principle: it stands for "Representational State Transfer" and it is important to note that it is not a programming language and it is not software that can be executed. REST is an architectural model that effectively corresponds to an abstraction of the structure and behavior of the World Wide Web.

Here, the architecture of a REST API is based on six principles that describe how networked resources on the Web, such as in a cloud, are defined and addressed. The principle of statelessness is essential for a REST API. This states that every REST message contains all the information necessary to understand that message. As with all of these principles, it is by no means specified how they must be implemented. Specifically, these are:

1. client-server architecture. The core of this principle is the separation of problems. And splitting the user interface from the data storage improves the portability of the user interface across multiple platforms. It also allows components to be developed independently. In the case of the REST interface, all resources must be identifiable by means of a unique resource identifier (URI for short).

2. statelessness The second important principle of REST is that communication must always be stateless. Thus, in REST, there are no user sessions realized with sessions and cookies. Conversely, this means that all required information is sent again with each request. The advantage (and main reason) of the statelessness of REST services is the easy scalability: If there are no sessions, multiple requests from a client can be easily distributed to different servers.

3. caching To improve network efficiency, clients can also store responses sent by the server and reuse them later for similar requests. This allows more responsive applications with greater efficiency and scalability.

4. Unified Interface In order for the components of a REST API to communicate with each other, they must follow the same rules. The goal of this is a simplified architecture and increased visibility of interactions.

5. layered system REST relies on multi-layered, hierarchical systems ("Layered System") - each component can only see directly adjacent layers and not beyond the immediate layer. Thus, for example, a client connecting to an intermediate component such as a proxy has no knowledge of what lies beyond it. This allows components to be independent of each other and thus easily interchangeable or extensible.

6. code-on-demand. Additional code can be downloaded to extend client functionality. However, as an optional principle, this condition may be disabled in certain contexts.

Applied to practice, this means the following using the example of a fictitious company that already relies on a REST interface: If the customer clicks on an item in the WebShop, the current item stock is queried in real time by the enterprise resource planning system and the customer can thus view it when placing an order. Thanks to the REST interface, this avoids the need to synchronize article inventories between two systems.

If the customer also clicks on "order with costs", REST ensures that all relevant information is transmitted both to the merchandise management system for delivery of the goods and to the payment service provider, which in turn confirms in real time whether the credit card specified is valid and the account is funded. Only after the payment service provider has given the go-ahead does the merchandise management system receive the information that this order can be processed further. In the process, the merchandise management system delivers the status of processing directly to the WebShop and the customer can track this via his customer account.

Furthermore, the desired shipping service provider is transmitted by the communication of the merchandise management with a multi-carrier service provider in the cloud via REST and the corresponding shipping label is produced. The customer receives an e-mail with the detailed tracking information when his goods are shipped and can directly track the path of his order until it arrives. The merchandise management system sets the shipping order to "completed" in all systems involved. This completes the entire process.