Representational State Transfer (REST) is an architectural style for distributed hypermedia systems that Roy Thomas Fielding described in his dissertation Architectural Styles and the Design of Network-based Software Architectures in 2000. An architecture style is the combination of various features of an IT system. A style contains rules or patterns to structure a system of different elements and connections. In contrast to design patterns, architectural styles describe the structure of a system as a whole and not the individual subcomponents and classes.
Grundlagen Representational State Transfer
The system must be built up in several layers. One layer offers the one lying above it
Shift certain services. In addition, the implementation details of a layer should be encapsulated from the outside world by an interface. Using
of layers, can reduce the dependencies between different components.
However, this concept has the disadvantage that all queries go through the different layers
must be passed through.
Code On Demand
Code on Demand is an optional requirement that states that the server has functionality
manipulate a client by transferring scripts.
Constraints des REST-Architekturstils
The REST architectural style describes six constraints that an application observes
must be in order to be labeled as RESTful.
Client-Server In general, the same properties apply to a REST architecture as to a client / -
Server architecture. The server is a web application and the client is a browser
or another application. By separating the user interface from the server component, clients are platform-independent.
Stateless The communication must be stateless, i.e. a message contains all information that is necessary for the client or the server to interpret it
can. Scalability is improved because no states have to be saved between requests
Cache Clients and servers are allowed to cache messages. To do this, the messages must contain information as to whether caching is permitted. This is necessary for the
Client does not use any out-of-date information. Caching allows some of the
Client-server interactions are avoided, thereby improving performance.
The central requirement that distinguishes the REST architecture style from other network-based architecture styles is the definition of a uniform interface between clients and servers. The interface must in turn meet four properties: The server does not make its capabilities available as a set of services and operations, but as resources that are identified via a URI. All information or objects such as B. Images, documents or people are mapped as a resource.
The representation of a resource is not fixed. This means that a server can deliver a resource in various representations such as JSON or XML. A client that has a representation of a resource available has all the information to delete or edit this resource from the server.
The representation of a resource is not fixed. This means that a server can deliver a resource in different representations such as JSON or XML. A client to which a representation of a resource is available has all the information to delete or edit this resource from the server.
The communication of a client with the server takes place via the standard methods GET, PUT, POST, DELETE and PATCH and not via application-specific operations.
The flow of control is controlled via hypermedia, also called HATEOAS. This means that the server tells the client which interactions are possible next when there are queries. A REST client then only needs a single entry URL and can dynamically request all the necessary information from the resources. The server can provide this information via hypermedia controls such as links. As a result, changes in the REST interface do not necessarily have to be adapted in the implementation of the client.
Richardson Maturity Model
To determine how strictly a service is based on REST, Leonard developed Richardson
with the REST Maturity model a four-level scale. In the following table are
the individual stages shown. All low level requirements must be from
einem höheren Level erfüllt sein.
0 • Only uses HTTP as a transport protocol for its own functions
(Tunnel). • Only uses a single HTTP method (e.g. POST).
• The content can be presented in any format.
• There is only one end point available. 1 • Several resources and thus different end points are available
Disposal. 2 • Uses multiple HTTP methods.
• HTTP protocol is no longer a tunnel.
• Uses HTTP status codes. 3 • Uses HATEOAS
Cloud Integration, iPaaS, SaaS, BPA… Ough, hard to keep track of all these terms. They are currently used frequently (and increasingly) in the context of automation, and it is sometimes difficult to make a clear distinction and distinction. We have already written blog posts on the terms iPaaS, SaaS and BPA, but we’ll take them up again here to make the difference.
But let’s start with cloud integration, because that’s the central umbrella term in which we embed all the other technologies in this blog post.
To illustrate these advantages, an example is suitable that we know well from our everyday work as an automation agency:
The central data to be used here is the data of a major customer. This can be the simplest information, such as the address. This address is required in numerous but completely different processes in the company: on the one hand, for correct invoicing in accounting. On the other hand, in the CRM system, where all the data of the large customer is also stored. But the address is also important in sales, for example, when employees go to the sales meeting on site.
Now the customer announces that the address of the company has changed after a move. This information will reach you by e-mail. There are now two options:
01. The e-mail is forwarded to all affected departments, accounting, sales, customer service, marketing… All persons open their corresponding program, CRM, accounting software, marketing tools (such as newsletter marketing) and change the data already stored there of the customer. This means that in multiple applications, different people do exactly the same thing: change one address. 02. But there is also an alternative: By connecting your applications, thus by integrizing them, the customer’s e-mail, or rather the information it contains about the address change, is automatically passed on to all affected applications: CRM, accounting, marketing, ERP. This does not require any clicks, because the cloud integration detects a trigger, i.e. address change, and thus automatically starts the process.
What sounds unimpressive in a single process becomes more effective when such a process occurs several times a day or weekly. Because there is a lot of data that is available in different applications and should always be correct. If these applications are cloud applications they are suitable for cloud integration.
But cloud integration doesn’t just happen. There are now a variety of applications that enable and implement this. Such tools usually allow us to link the relevant cloud applications on a central platform and define clear rules on when, how, where, how much data should be passed on and what happens to them.
IPaaS, SaaS, BPA, ABC – who can still see through it?
To realize cloud integration, there are various applications and technologies that are sometimes used interchangeably.
Cloud integration cannot be done without SaaS, iPaaS and BPA
Cloud integration is rather an umbrella term that includes numerous technologies, such as SaaS, iPaaS and BPA, and this is also absolutely necessary. Cloud integration is a concept that is made possible by appropriate technologies.
However, all terms share the commonality that they are cloud-based and thus offer enormous potential for growth and scaling. In addition, they are often cheaper to implement and maintain because changed requirements are easy to implement.
As an independent automation agency, we implement cloud integration according to your requirements. We use a variety of SaaS tools and iPaas (strictly speaking BPA) software. Together we find individual solutions that are flexible and scalable.