What is REST? Use in industry

1. Core idea of REST

The idea of “Representational State Transfer” (REST) consists of a software architecture for data exchange between software systems (client-server). The special feature compared to other architectures is the very simple implementation, the concentration on resources and the statelessness.
All communication via REST focuses on the resource and not the action. A resource is always uniquely addressed and then the basic actions of creating, reading, changing or deleting can be carried out. In this context, stateless means that all descriptive parameters are exchanged between client and server. The advantage here is that there are no sessions. Without sessions, client and server systems can be scaled freely because each REST call is completed and understandable on its own, without the preceding or following ones.

2. REST API / Interface

The API (Application Programming Interface) is the respective implementation of the REST architecture of a concrete system. It is then referred to as a RESTful API. The resources that can be addressed via REST are defined in the interface.
For the respective resources, there are associated parameters that describe the resource and that are modified via REST.
For the RESTful API of a system, the provider usually provides API documentation in which all resources and their parameters can be viewed.
An example of good API documentation is the REST interface of our ticket system Target Process, which can be viewed here: Target Process REST API.
In a production environment, a REST-enabled system might provide the following resources, for example:

• /production/production order
  • Parameters: ID, order number, quantity, product, deadline, …
• /production/production-order/{id}/component.
  • Parameters: ID, material number, quantity, batch, …
• /production/plant
  • Parameter: ID, status, current order, next maintenance, operating hours, …

3. REST and HTTP

The architectural idea of Representational State Transfer does not prescribe a technology for implementation. In practice, however, REST is always implemented with the HTTP protocol. The resources are addressed with a unique URI (Uniform Resource Identifier), as known from the web browser. The parameters of the resource are appended as a query (also known as URL parameters).
The actions on the resources are implemented in HTTP with the standard actions GET, POST, PUT and DELETE. The following standard applies:

• GET retrieves one or more resources
• POST creates a new instance of a resource
• PUT writes data to a resource and thus changes it
• DELETE deletes an instance of a resource

A REST call to retrieve a specific production order from a REST-enabled ERP system could then look like this via an existing http connection:

GET http://ERPSYSTEM/Produktionsauftrag/4711
Accept: application/json

The second line specifies to the ERP system the format in which the response is to be made.

A possible response in JSON format would be:

[
{
„id“: „4711“,
„Artikel“: “Produkt A”,
„Menge“: „10500,
„Freigabe“: false,
„Lieferdatum”: „21.7.2020“
}
]

4. Example

A real example of a REST call can be tried out, for example, on the page of the weather forecast service OpenWeatherMap.

If the link is called with the web browser (per click), a GET request is sent to the service. As a result, the service responds with the weather forecast for the location London.
The endpoint in this case is: api.openweathermap.org/data/2.5/forecast
The resource is the “forecast” with the associated parameters “q” for the location and “mode” for the format. A detailed example of how to call this API can be found in our instruction article for retrieving weather data from OpenWathermap with the OPC Router.

5. Data formats

The data format of the response of a REST endpoint is not prescribed and can therefore in principle be arbitrary. In practice, the format depends on the function of the endpoint. In most cases, the data is delivered as a JSON or XML document. If a normal web page is queried via a REST call, the response is in HTML.
The structure of XML/JSON responses must be documented by the operator of the REST interface, as there is no possibility of self-description here.

6. Service / Webservice

In relation to software, a web service or service refers to a service that allows data exchange and cooperation between different software systems. The web service makes this possible on the web through standard web technologies. Among many others, REST is a concrete manifestation of a web service implementation. Others are, for example, SOAP or RPC (Remote Procedure Call).

7. Sensors with REST

Many field devices with built-in small computers also offer their data via REST. In this way, these field level devices can be easily integrated into other applications.
Examples of this are I/O modules (e.g. from WuT) or energy measuring devices (e.g. from Phoenix Contact).
For controllers (PLCs) and other remote data sources, the Kepware OPC server also offers the possibility of providing data via REST server.

8. Software systems with REST

The REST interface is widely used in software systems (e.g. ERP, MES, PLS) and especially on the web in cloud-based systems. With a well-equipped API, almost the entire functional scope of the software system can be addressed via the interface or, alternatively, user-specific REST endpoints can be created.
Examples of this are, among many others, SAP with REST via PI, Microsoft with the REST API for Dynamics 365 or the Siemens Mindsphere REST API. Ultimately, however, it is worth asking the manufacturer about a REST API for every software system used.

9. The Endpoint

10. OPC Router and REST

The OPC Router serves as a REST client when calling a REST API (see REST Plug-in). In the OPC Router the endpoint is configured for the call and then called in a connection. The method, the endpoint and the parameters are then visible in the transfer object.

A detailed example can be found here: Query weather data from OpenWeather with REST.

Besides calling REST endpoints, the OPC Router can also act as a server and define REST endpoints. For this purpose, the OPC Router provides so-called REST triggers. In this way, an own REST API can be built with the OPC Router.

11. Postman – Test API Client

There are various tools for quick and easy testing of REST interfaces. One of the best known is Postman. A very powerful programme for calling and creating APIs. Postman can be downloaded here: Postman REST API Client.

12. Swagger – Framework for API Description

The Swagger framework is used to create, use and document web services. This is particularly helpful for REST clients, as a REST API documented via Swagger provides standardised documentation so that browsing of the interface is possible in the client. This browsing functionality is not included in the core idea of REST and is supplemented herewith.

13. History of REST

Web services have been an important topic in distributed software systems from the beginning. Many technologies quickly became very powerful and provided many functions. For smaller applications, these were then often already too complex and too computationally intensive.
In 2000, the American computer scientist Roy Fielding took this as an opportunity to design a new, simple architecture. He was awarded a doctorate for it. Since then, REST has become widespread and is one of the most important system coupling techniques on the internet.

14. Future of REST – GraphQL

The architecture model of REST is fixed and operated as it is. The lack of structure in REST queries has led to new developments that take the idea of REST architecture and develop it further. Facebook developed the GraphQL architecture in 2012 and released it in 2015. Just like REST, GraphQL is a stateless query language. Among some other improvements, GraphQL defines schemas. This defines how an endpoint responds and the structure of the data in the response. GraphQL thus improves the architecture in one of the biggest weak points of REST.

15. Security in REST

Since HTTP is used to call REST endpoints, the authentications available in the standard can also be used, such as: HttpBasic, Jwt, Ntml, OAuth1, OAuth2.
In addition, https is of course used instead of http in order to use a tap-proof connection.
In addition to the standard authentication options, a so-called AppKey is often exchanged. This key is a secret code created for the client that is transferred with every call in order to obtain authorisation for the call. The so-called Bearer Token is also supported by the OPC Router. REST is considered secure due to the use of widely used methods.

16. Video: Tutorial REST Plug-in

In this video we explain how to integrate the OPC Router into your REST communication. In the first example we request weather data from OpenWeather. In the second example we show you how to configure and test a REST-ful interface on the OPC Router to read out order data from a database.