Die Automatisierung der Zukunft heißt IIoT, smarte Fabriken und intelligente Geräte. Das Herzstück dieses neuen technologischen Zeitalters ist die Konnektivität. Statt starrer, hierarchischer Automatisierungspyramiden mit trennenden Zwischenebenen werden vielmehr umfangreichere Netzwerkstrukturen etabliert, in denen einzelne Knotenpunkte miteinander verknüpft sind und Daten untereinander austauschen.

Um solche eine smarte Vernetzung umzusetzen, braucht es IIoT-fähige Geräte. Diese standardisiert, skalierbar, IT- und OT-fähig sowie interoperabel sein. Zusätzlich müssen sie sicher kommunizieren können. Dazu stehen unterschiedliche Kommunikationsprotokolle für zur Verfügung: MQTT, OPC UA, AMQP und REST API ermöglichen die smarte Kommunikation. Erfahren Sie in unserer mehrteiligen Reihe an Blogartikeln, welche Eigenschaften das jeweilige IIoT-Kommunikationsprotokoll kennzeichnen und für welche Anwendungsfälle es sich besonders eignet. Der vierte Teil der Artikelserie dreht sich um REST API.

Blog-Serie: IIoT-Kommunikationsprotokolle

Was ist REST API und wie funktioniert es?

Representation State Transfer (REST) fasst architektonische Rahmenbedingungen zusammen, mit denen die Kommunikation zwischen Geräten in einem Netzwerk vereinfacht und harmonisiert wird. Es wurde im Jahr 2000 von Roy Fielding im Rahmen seiner Doktorarbeit zum Ph. D. entwickelt. REST kann auf Basis jedes Protokolls implementiert werden, hat sich jedoch in Internet-Netzwerken etabliert und ist am bekanntesten für die Festlegung architektonischer Rahmenbedingungen auf Basis der HTTP(S)-Spezifikation. HTTP ist ein weit verbreitetes Request/Response-Protokoll auf der Anwendungsschicht. Wenn jedoch jeder HTTP nach seinen eigenen Vorstellungen verwenden würde, könnte keine Synchronisierung und somit keine Kommunikation zwischen den Komponenten erfolgen. Hier schuf REST Abhilfe und harmonisierte die HTTP-Nutzung. Die Kernidee hinter REST ist die Übertragung des Zustands (vom Server) auf repräsentative Weise (zum Client). Es gibt zwei wichtige Punkte, die hier erwähnt werden sollten. Einerseits ist der Server zustandslos. Es werden keine Zustandsinformationen darüber gespeichert, ob und wann er mit einem Client verbunden war. Er sendet nur den momentanen Zustand an den Client und der Client kann eine zustandsbasierte Anwendung erstellen, die auf den jeweiligen Zuständen basiert, die er vom Server erhält. Zudem kann der Server die Ressourcen in mehreren repräsentativen Formaten an den Client senden. Jede Dateneinheit, auf die der Client in REST zugreifen kann, wird als Ressource bezeichnet und ist über einen eindeutigen Zugriffspunkt erreichbar, der als Uniform Resource Identifier (URI) bezeichnet wird. Jede Ressource hat einen URI.

Ein Nutzen von REST besteht darin, dass die Ressourcen von ihrer Repräsentation entkoppelt sind. Der Server kann die Ressourcen in einem beliebigen Format speichern (in einer Datenbank, einer CSV-Datei oder einer objektorientierten Klasse). Dennoch kann er die Ressourcen in einem oder mehreren Darstellungsformaten wie Binary, JSON, XML, YAML oder JPEG bereitstellen. Das bedeutet, dass der Client auf die Darstellung zugreift, nicht jedoch auf die Ressource selbst. Anwendungen und Schnittstellen, die REST verwenden, werden als RESTful bezeichnet.

Damit eine Schnittstelle oder Anwendung als RESTful gilt, müssen die folgenden fünf Rahmenbedingungen eingehalten werden:

Client/Server

Die Kommunikation sollte zwischen einem Client und einem Server stattfinden. Wie bereits erwähnt, ist der Client der Suchende und der Server der Lieferant der Information. Beispiel: In Abbildung 1 fragt der Client den Server nach der Temperatur und der Server antwortet mit einer Nachricht, die die Temperatur in einem JSON-Format enthält. Zwei zentrale Komponenten sollten unbedingt in der Client-Anfrage enthalten sein: ein URI und eine HTTP-Methode. Die http-Methoden sind Aktionen, die durch den Client vom Server angefordert werden. Es gibt sechs Standard-HTTP-Methoden (GET, PUT, POST, DELETE, HEAD und OPTIONS), die jeweils in bestimmten Situationen verwendet werden. Beispielsweise sollte GET verwendet werden, um den Zustand einer Ressource zu empfangen, PUT, um eine Ressource zu aktualisieren, POST, um eine Ressource zu erstellen, und DELETE, um eine Ressource zu löschen.

Zustandslosigkeit

Der Server merkt sich nicht, mit welchem Client er gesprochen hat. So wird die Verantwortung für das Speichern des jeweiligen Zustands auf die Client-Seite verlagert, wodurch der Server kompakter implementiert werden kann.

Cachingfähig

Der Server enthält Informationen, ob seine Ressourcen für das Caching geeignet sind. Wenn dies der Fall ist, enthalten die Ressourcen Versionsnummern, damit der Client Informationen zu Gültigkeit und Verlauf erhält.

Mehrere Ebenen

Unabhängig davon, wie viele Ebenen zwischen dem Client und dem Server liegen, sollten diese in der Lage sein, miteinander zu kommunizieren, selbst wenn Proxys zwischen ihnen stehen. Es können mehrere Ebenen vorhanden sein, wie die Sicherheitsebene, die Caching-Ebene und die Load-Balancing-Ebene, aber sie sollten den Client und die Nachrichtenübertragung des Servers nicht beeinträchtigen.

Einheitliche Schnittstelle

Für eine einheitliche Schnittstelle müssen mehrere Bedingungen erfüllt sein:

• Jede Ressource muss ihre eindeutige Kennung in Form eines URIs haben.
• Sobald der Client eine Darstellung einer Ressource und ihrer Metadaten (und eine entsprechende Berechtigung) hat, kann er eine Ressource hinzufügen, löschen oder ändern.
• Die ausgetauschten Nachrichten sollten selbstbeschreibend sein und ausreichende Informationen zur Verarbeitung der Ressourcen enthalten.
• Ressourcen sind miteinander verknüpft und der Client kann Informationen über die URIs aller Ressourcen erhalten, indem er auf einen bestimmten URI zugreift.

Interoperabilität von REST API

Die RESTful-Schnittstelle bietet mehrere Standardisierungsmöglichkeiten auf einer syntaktischen Ebene wie OpenAPI, RAML, API und Blueprint. Sie sind Standards für die Beschreibung der RESTful-Schnittstellen für Menschen und Computer und ermöglichen die Interaktion miteinander, ohne dass jemals ein Handbuch geöffnet werden muss. Dies befähigt die RESTful-Schnittstelle sowohl zur Maschine-Maschine- als auch zur Mensch-Maschine-Interaktion. Für die Maschine-Maschine-Interaktion können beide Maschinen die REST-APIs von ihren Kommunikationspartnern verarbeiten und ohne menschliches Eingreifen auf Daten zugreifen. Nur für den Fall, dass eine sinnvolle Anwendung erstellt werden soll (semantische Interoperabilität), muss ein Mensch mit dem System interagieren. In Bezug auf die Mensch-Maschine-Interaktion ermöglichen mehrere repräsentative Tools ein einfaches Verständnis von und eine einfache Interaktion mit der REST API.

Echtzeitverhalten von REST API

Die RESTful-Schnittstelle, bei der HTTP ein Request/Response-Kommunikationsprotokoll ist, verfügt nicht über Echtzeitfunktionen. Die Geschwindigkeit der Datenaktualisierung hängt davon ab, wie häufig der Client den Server abfragt. Bei zu vielen Abfragen kann das Netzwerk überlastet werden.

Sicherheit von REST API

Die RESTful-Schnittstelle verfügt über keine eigenen Sicherheitsmechanismen, da zum Zeitpunkt ihrer Entwicklung die Sicherheit nicht im Vordergrund stand. Dennoch gibt es viele Best Practices, darunter die Authentifizierung mit Benutzername und Kennwort, JWT-Token und OAuth-Sicherheitsmechanismen.

Implementierung von REST API verglichen mit MQTT, OPC UA und AMQP

MQTT und AMQP sind so kompakt wie möglich gestaltet, sodass es keinen Spielraum und keine Notwendigkeit für Optimierungen gibt, abgesehen vom Einbeziehen oder Ausschließen von Sicherheitsfunktionen. Dasselbe gilt für die RESTful-Schnittstelle. Allerdings erfordert es etwas an Aufwand: Die RESTful-Schnittstelle ist nicht so einfach wie MQTT und nicht so komplex wie OPC UA und AMQP. Eine Anwendung kann sehr schnell entwickelt werden, insbesondere wenn HTTP bereits als Protokoll verfügbar ist. Größer wird die Herausforderung aus der Implementierungsperspektive, wenn die REST API viele Ressourcen enthält.

Anwendung von REST API

Die RESTful-Schnittstelle ist seit Langem ein Standard im Internetsektor und die meisten Benutzer sind damit vertraut. Sie eignet sich ideal, wenn zwischen zwei Parteien eine direkte Kommunikation stattfindet, die leicht verständlich und nutzbar sein sollte, auch für Menschen. Nur sehr wenige Unternehmen verzichten für die eigenen Geräte oder die Dienstleistungen, die sie bereitstellen, auf eine RESTful-Schnittstellendefinition. Auch Pepperl+Fuchs setzt bei seinen Sensoren auf eine RESTful-API. REST lässt sich zudem sehr einfach im Backend einer Website parsen und optimal benutzerfreundlich präsentieren.

White Paper: TCP-basierte Kommunikationsprotokolle

Erfahren Sie mehr über die Gemeinsamkeiten und Unterschiede der vier IIoT-Kommunikationsprotokolle REST API, MQTT, OPC UA und AMQP.

Weitere Informationen

• Vollständige Infrastruktur für Cloud-basierte IoT-Anwendungen
• IIoT-Technologien und Lösungen für Industry 4.0 Anwendungen
• Industrial Communication Geräte