Introduction

When systems are coupled, REST plays almost a key role. Especially in the context of web-enabled systems, REST is one of the leading standards for system integration. REST is by no means brand new, on the contrary, the concept behind REST is well-tried. Connecting systems via REST is simple and effective due to its simple design. And because of its statelessness it is easy to scale. In the industrial sector REST is used in many places. Here we provide you with the necessary basic knowledge about REST.

Content

REST

Core idea of REST

The idea of “Representational State Transfer” (REST) consists of a software architecture for data exchange between software systems (client-server). What makes it special compared to other architectures is the very simple implementation, the concentration on resources and the statelessness.
Any communication via REST focuses on resources and not on action. A resource is always uniquely addressed and the basic actions create, read out, change or delete can be executed afterwards. Stateless in this context means that all descriptive parameters are exchanged between client and server. The advantage here is, 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.

REST API Schnittstelle

REST API / Interface

API (Application Prgramming 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 each resource, there are associated parameters that describe the resource and that are modified by REST.
For the RESTful API of a system, the provider normally provides API documentation in which all resources and their parameters can be viewed.

An example for a 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 capable system could provide the following resources:

  • /Production/production order
    • Parameters: ID, order number, quantity, product, date…
  • /production/production order/{id}/component
    • Parameters: ID, material number, quantity, batch…
  • /Production/Plant
    • Parameters: ID, status, current job, next maintenance, operating hours, …

REST and HTTP

The architectural idea of the Representational State Transfer does not prescribe any technology for implementation. In practice, however, REST is always implemented using the HTTP protocol. The resources are addressed with a unique URI (Uniform Resource Identifier) as known from the web browser. The resource parameters are appended as a query (also known as URL parameters).
The actions on the resources are converted 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 changes it
  • DELETE deletes an instance of a resource

A REST call to retrieve a specific production order from a REST capable ERP system could look like this over an existing http connection

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

The second line tells the ERP system in which format the response should be sent.

A possible response in JSON format would be

[
{
“id”: “4711”,
“Article”: “Product A”,
“Quantity”: “10500,
“Release”: false,
“Delivery date”: “21.7.2020”
}
]

OPC Foundation

Example

A real example of a REST-call can be tried out on the page of the weather forecast service OpenWeatherMap.
The URL for this is:
http://api.openweathermap.org/data/2.5/forecast?q=London,us&mode=xml

If the link is called with the web browser (by clicking), a GET request is sent to the service. As a result, the service responds with the weather forecast for London.
The end point 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. For a detailed example of how to call this API, please refer to our tutorial article on how to retrieve weather data from OpenWathermap with the OPC Router.

Data formats

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

Service / Webservice

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

Sensors with REST

Many field devices with built-in small computers also offer their data via REST. This allows these field level devices to be easily integrated into other applications.
Examples are I/O modules (e.g. from WuT) or energy measuring devices (e.g. from Phoenix Contact).
For controllers (PLC) and other IT remote data sources, the Kepware OPC Server also provides a way to provide data via REST server.

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.

REST Endpunkt

The endpoint

Endpoints are the full URIs that make up the respective REST API. The sum of all endpoints is the API and the individual endpoint addresses exactly one resource. For the example of the production order, an end point for querying a component quantity could look like this

/production order/{id}/component/{id}/quantity

In this end point, the numbers for order and component are transferred as ID.

OPC Router and REST

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

OPC Router und REST

A detailed example can be found here: Instructions for retrieving weather data from OpenWathermap with the OPC Router

Besides calling REST end points the OPC Router can also serve as a server and define REST end points. For this purpose the OPC Router provides so-called REST triggers. In this way, the OPC Router can be used to build its own REST API.

Postman

Postman – Test API Client

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

Swagger

Swagger – Framework for API Description

The Swagger Framework is used to create, use and document web services. This is especially helpful for REST clients, because a REST API documented by Swagger provides standardized documentation, so that browsing the interface is possible in the client. This browsing functionality is not included in the core idea of REST and is hereby supplemented.

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 the title of Doctor for this. Since then, REST has spread widely and serves as one of the most important system coupling techniques on the Internet.

Future of REST – GrapQL

The architecture model of REST is fixed and is operated as it is. The lack of structures in REST queries has led to new developments that take up and develop the idea of the REST architecture. Facebook has 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 for one of the major weaknesses of REST.

Security in REST

Since HTTP is used to call REST endpoints, the authentications available in the standard system 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.
Besides the standard authentication options, a so-called AppKey is often exchanged. This key is a secret code created for the client, which is transferred with every call to get the authorization 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.

Video “Tutorial: RESTful Plug-in”

In this video we explain how to integrate OPC Router into your REST communication. In the first example we query 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 order data from a database.

Run a free test now!

Get your personal link to the most recent OPC Router version and sign up for product news.

Test now!