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.
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.
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.
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
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.
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
• 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.
Arrange a free cloud integration consultation now
Arrange a free cloud integration consultation now
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.
To realize cloud integration, there are various applications and technologies that are sometimes used interchangeably.
We have made a first distinction between iPaaS and BPA here.
We explain the term SaaS in more detail here.
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.