Einleitung

Wenn es um die Kopplung von Systemen geht, dann spielt REST nahezu immer eine Schlüsselrolle. Gerade im Zusammenhang mit webfähigen Systemen ist REST für die Systemintegration einer der führenden Standards. Dabei ist REST keineswegs brandneu, im Gegenteil, das Konzept hinter REST ist altbewährt. Das Verbinden von Systemen per REST ist aufgrund seiner einfachen Gestaltung simpel und effektiv. Und durch die Zustandslosigkeit ist die einfache Skalierbarkeit gegeben. Im industriellen Bereich ist REST an vielen Stellen im Einsatz. Wir versorgen Sie hier mit dem notwendigen Basis-Wissen rund um REST.

Inhalt

REST

Kernidee von REST

Die Idee des “Representational State Transfers” (REST) besteht in einer Softwarearchitektur für Datenaustausch zwischen Softwaresystemen (Client-Server). Das besondere gegenüber anderen Architekturen ist die sehr einfache Umsetzung, die Konzentration auf Ressourcen und die Zustandslosigkeit.
Jegliche Kommunikation per REST stellt die Ressource in den Mittelpunkt und nicht die Aktion. Eine Ressource wird immer eindeutig adressiert und anschließend können die Grundaktionen Erstellen, Auslesen, Ändern oder Löschen ausgeführt werden. Zustandlos heißt in diesem Zusammenhang, dass jeweils alle beschreibenden Parameter zwischen Client und Server ausgetauscht werden. Der Vorteil liegt hier im Verzicht auf Sessions. Ohne Sessions könne Client- und Server-Systeme frei skaliert werden, weil jeder REST Aufruf alleinstehend abgeschlossen und verständlich ist, ohne die vorhergehenden oder folgenden.

REST API Schnittstelle

REST API / Schnittstelle

Die API (Application Prgramming Interface) ist die jeweilige Implementierung der REST Architektur eines konkreten Systems. Es wird dann von einer RESTful API gesprochen. In der Schnittstelle werden die Ressourcen definiert, die per REST angesprochen werden können.
Zu den jeweiligen Ressourcen gibt es zugehörige Parameter, welche die Ressource beschreiben und die per REST modifiziert werden.
Für die RESTful API eines Systems stellt der Anbieter im Normalfall eine API Dokumentation bereit, in der alle Ressourcen und deren Parameter einsehbar sind.
Ein Beispiel für eine gute API Dokumentation ist die REST Schnittstelle unseres Ticketsystems Target Process, die hier eingesehen werden kann: Target Process REST API.
In einer Produktionsumgebung könnte ein REST-fähiges System zum Beispiel folgende Ressourcen bereitstellen:

  • /Produktion/Produktionsauftrag
    • Parameter: ID, Auftragsnummer, Menge, Produkt, Termin, …
  • /Produktion/Produktionsauftrag/{id}/Komponente
    • Parameter: ID, Materialnummer, Menge, Charge, …
  • /Produktion/Anlage
    • Parameter: ID, Status, aktueller Auftrag, nächste Wartung, Betriebsstunden, …

REST und HTTP

Die Architektur-Idee des Representational State Transfers schreibt keine Technologie für die Umsetzung vor. In der Praxis wird REST allerdings immer mit dem HTTP-Protokoll realisiert. Die Ressourcen werden dabei mit einem eindeutigen URI (Uniform Ressource Identifier) adressiert, wie man es aus dem Webbrowser kennt. Die Parameter der Ressource werden als Query angehängt (auch als URL-Parameter bekannt).
Die Aktionen auf die Ressourcen werden in HTTP mit den Standard Aktionen GET, POST, PUT und DELETE umgesetzt. Dabei gilt folgender Standard:

  • GET ruft eine oder mehrere Ressourcen ab
  • POST erzeugt eine neue Instanz einer Ressource
  • PUT schreibt Daten auf eine Ressource und ändert sie damit
  • DELETE löscht eine Instanz einer Ressource

Ein REST Aufruf zum Abruf eines bestimmten Produktionsauftrags von einem REST-fähigen ERP System könnte über eine bestehende http-Verbindung dann z.B. so aussehen:

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

Die zweite Zeile gibt dem ERP-System dabei vor, in welchem Format die Antwort erfolgen soll.

Eine mögliche Antwort im JSON-Format wäre:

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

OPC Foundation

Beispiel

Ein reales Beispiel für einen REST-Aufruf lässt sich zum Beispiel auf der Seite des Wetter-Vorhersage-Dienstes OpenWeatherMap ausprobieren.
Die URL hierfür ist:
http://api.openweathermap.org/data/2.5/forecast?q=London,us&mode=xml

Wird der Link mit dem Webbrowser aufgerufen (per Click), wird eine GET Anfrage an den Dienst gesendet. Als Ergebnis antwortet der Dienst mit der Wetter-Vorhersage für den Ort London.
Der Endpunkt ist in diesem Fall: api.openweathermap.org/data/2.5/forecast
Die Ressource ist der “forecast” mit den zugehörigen Parametern “q” für den Ort und “mode” für das Format. Ein ausführliches Beispiel für den Aufruf dieser API finden Sie in unserem Anleitungsartikel für den Abruf von Wetterdaten von OpenWathermap mit dem OPC Router.

Datenformate

Das Datenformat der Antwort eines REST-Endpunkts ist nicht vorgeschrieben und kann daher im Prinzip beliebig sein. In der Praxis richtet sich das Format nach der Funktion des Endpunkts. In den meisten Fällen werden die Daten als JSON- oder als XML-Dokument geliefert. Wird eine normale Webseite per REST-Aufruf abgefragt, erfolgt die Antwort in HTML.
Die Struktur von XML/JSON Antworten muss vom Betreiber der REST Schnittstelle dokumentiert werden, da es hier keine Möglichkeit der Selbstbeschreibung gibt.

Service / Webservice

Ein Webservice bzw. Service bezeichnet in Bezug auf Software einen Dienst, der den Datenaustausch und die Zusammenarbeit von verschiedenen Softwaresystemen erlaubt. Der Webservice ermöglicht dies dabei im Web durch Standard-Webtechnologien. Neben vielen weiteren ist REST eine konkrete Ausprägung einer Webservice-Umsetzung. Andere sind zum Beispiel SOAP oder RPC (Remote Procedure Call).

Sensoren mit REST

Viele Feldgeräte mit eingebauten Kleinrechnern bieten Ihre Daten auch über REST an. So können diese Feldebenen-Geräte einfach in andere Anwendungen integriert werden.
Beispiel hierfür sind I/O-Baugruppen (z.B. von WuT) oder Energiemessgeräte (z.B. von Phoenix Contact).
Für Steuerungen (SPS) und andere IT-fernere Datenquellen bietet der Kepware OPC Server auch eine Möglichkeit Daten per REST Server anzubieten.

Softwaresysteme mit REST

Eine große Verbreitung der REST-Schnittstelle findet sich bei Softwaresystemen (z.B. ERP, MES, PLS) und vor allem im Web bei Cloud-basierten Systemen. Bei einer gut ausgestatteten API kann nahezu der gesamte Funktionsumfang des Softwaresystems über die Schnittstelle angesprochen werden oder es können alternativ benutzerspezifische REST Endpunkte geschaffen werden.
Beispiele hierfür sind neben vielen anderen SAP mit REST über PI, Microsoft mit der REST API für Dynamics 365 oder die Siemens Mindsphere REST API. Letztendlich lohnt aber bei jedem einsetzten Softwaresystem die Frage an den Hersteller nach einer REST API.

REST Endpunkt

Der Endpunkt

Endpunkte sind die vollen URIs, aus denen sich die jeweilige REST API zusammensetzt. Die Summe aller Endpunkte ist die API und der einzelne Endpunkt spricht genau eine Ressource an. Für das Beipspiel des Produktionsauftrags könnte ein Endpunkt zur Abfrage einer Komponentenmenge wie folgt aussehen:

/Produktionsauftrag/{id}/Komponente/{id}/Menge

Wobei in diesem Endpunkt die Nummern für Auftrag und Komponente als ID übergeben werden.

OPC Router und REST

Der OPC Router dient als Client beim Aufruf einer REST API (s. REST Plug-in ). Im OPC Router wird der Endpunkt für den Aufruf konfiguriert und dann in einer Verbindung aufgerufen. Im Transferobjekt sind dann die Methode, der Endpunkt und die Parameter ersichtlich:

OPC Router und REST

Ein detailliertes Beispiel ist hier zu finden: Anleitungsartikel für den Abruf von Wetterdaten von OpenWathermap mit dem OPC Router

Neben dem Aufruf von REST Endpunkten kann der OPC Router auch als Server dienen und REST Endpunkte definieren. Dafür stellt der OPC Router sogenannte REST Trigger bereit. Auf diese Weise kann mit den OPC Router eine eigene REST API aufgebaut werden.

Postman

Postman – Test API Client

Zum schnellen und einfachen Testen von REST Schnittstellen gibt es verschiedene Tools. Eines der bekanntesten ist der Postman. Ein sehr mächtiges Programm zum Aufrufen und Erstellen von APIs. Postman kann hier heruntergeladen werden: Postman REST API Client.

Swagger

Swagger – Framework für API Beschreibung

Das Swagger Framework dient zur Erstellung, Nutzung und Dokumentation von Webservices. Für REST Clients ist dies besonders hilfreich, da eine per Swagger dokumentierte REST API eine standardisierte Dokumentation bereitstellt, so dass im Client ein Browsing der Schnittstelle möglich ist. Diese Browsing-Funktionalität ist nicht in der Kernidee von REST enthalten und wird hiermit ergänzt.

Geschichte von REST

Webservices waren von Beginn an ein wichtiges Thema in verteilten Softwaresystemen. Viele Technologien wurden schnell sehr mächtig und stellten viele Funktionen bereit. Für kleinere Anwendungen waren diese dann oftmals bereits zu komplex und zu rechenintensiv.
Im Jahr 2000 nahm das der amerikanische Informatiker Roy Fielding zum Anlass eine neue einfache Architektur zu entwerfen. Ihm wurde dafür der Doktor-Titel verliehen. Seitdem hat REST sich stark verbreitet und dient als einer der wichtigsten Systemkopplungs-Techniken im Internet.

Zukunft von REST – GraphQL

Das Architekturmodell von REST ist fix und wird so wie es ist betrieben. Die fehlenden Strukturen in REST Abfragen haben dazu geführt, dass es neue Entwicklungen gibt, welche die Idee der REST Architektur aufnehmen und weiterentwickeln. Facebook hat 2012 die GraphQL Architektur entwickelt und 2015 veröffentlicht. Genau wie REST ist GraphQL eine zustandslose Abfragesprache. Neben einigen anderen Verbesserungen werden in GraphQL Schemas definiert. Damit ist festgelegt, wie ein Endpunkt antwortet und wie die Struktur der Daten in der Antwort sind. GraphQL verbessert die Architektur damit bei einem der größten Schwachpunkte von REST.

Sicherheit in REST

Da für den Aufruf von REST Endpunkten HTTP verwendet wird, können auch die im Standard verfügbaren Authentifizierungen genutzt werden, wie z.B.: HttpBasic, Jwt, Ntml, OAuth1, OAuth2.
Zusätzlich wird statt http natürlich https genutzt, um eine abhörsichere Verbindung zu nutzen.
Neben den Standard Authentifizierungsmöglichkeiten wird oft auch ein sogenannter AppKey ausgetauscht. Dieser Key ist ein für den Client erstellter, geheimer Code, der bei jedem Aufruf mit übergeben wird, um so die Berechtigung für den Aufruf zu bekommen. Auch der sogenannte Bearer Token wird vom OPC Router unterstützt.
REST ist durch die Nutzung weit verbreiteter Methoden als sicher anzusehen.

Video “Tutorial: RESTful Plug-in”

In diesem Video erklären wir Ihnen, wie Sie den OPC Router in Ihre REST-Kommunikation einbinden. Im ersten Beispiel fragen wir Wetterdaten bei OpenWeather ab. Im zweiten Beispiel zeigen wir Ihnen, wie Sie am OPC Router eine REST-ful Schnittstelle zum Auslesen von Auftragsdaten aus einer Datenbank konfigurieren und testen können.

Testen Sie jetzt den OPC Router!

Kostenlos & Unverbindlich

Erhalten Sie den Link zum aktuellen OPC Router und verpassen Sie keine der Produkt-Neuerungen.

Ja, ich möchte jetzt kostenlos testen