Da REST kein ausspezifizierter Standard ist, gibt es somit nicht im Detail vor, wie konforme Implementierungen aussehen müssen, sondern gibt sechs Architekturprinzipien (Constraints) vor, die eingehalten werden müssen. Technologisch setzt REST auch auf Bestehendes, so kommt bei der Übertragung oft HTTP/S als Protokoll und XML (Extensible Markup Language) oder JSON (Java Script Object Notation) als Datenformat für Informationen zum Einsatz. Da REST im Jahr 2000 entwickelt wurde während des großen Durchbruchs des Internets, liefert das selbige bereits einen großen Teil der für REST nötigen Infrastruktur und die meisten Webservices basieren auf REST. Die sechs von REST definierten Architekturprinzipien sind dabei: REST baut auf ein Client-Server-Modell mit strikter Trennung von Datenhaltung und User-Interface. Das bedeutet, dass User-Interfaces als Clients leicht an unterschiedliche individuelle Rahmenbedingungen angepasst werden können während die Datenhaltung als Server durch einen standardisierten Aufbau leicht zu skalieren ist. Nachrichten müssen zustandslos (stateless) sein. Eine Anfrage des Clients beim Server muss somit in sich geschlossen sein und alle Information zum Applikationszustand beinhalten. Der Kontext der Nachricht muss also immer mitgeliefert werden, da es bei REST keine bestehenden Sitzungen gibt und der Server diese ansonsten nicht interpretieren kann.
Dieses Prinzip sorgt ebenfalls für eine einfachere Skalierbarkeit, da verschiedene Nachrichten des Clients von unterschiedlichen Servern bearbeitet werden können. Der Client hat die Möglichkeit, Antworten des Servers für eine erneute identische Anfrage zu Puffern (Cachen) sofern diese entsprechend gekennzeichnet sind. Dies dient dazu, den Traffic auf dem Netzwerk zu verringern und die Effizienz des Netzwerks zu erhöhen. Allerdings besteht das Risiko, dass der Client so auf veraltete Daten zurückgreift. REST setzt auf eine einheitliche Schnittstelle zwischen allen Clients und Servern mit einheitlichen Protokollen, Datenformaten und Methoden zum Zugriff. Mit der Verwendung von einheitlichen Schnittstellen gehen in der Regel Performanceeinbußen einher, da alle Daten in ein einheitliches Format gewandelt werden müssen. Diese Einbußen nimmt man für eine einfachere Architektur und Usability aber gerne in Kauf. REST gibt eine Architektur in einem Schichtensystem vor mit klarer hierarchischer Struktur und Abgrenzung zwischen den Schichten. Dieser Ansatz ermöglicht es, stärker zu abstrahieren und so dem Anwender über eine einheitliche Schnittstellenschicht Zugriff auf unterschiedliche dahinterliegende Architekturen zu geben ohne dass er diese kennen muss. Dadurch ist es z. B. möglich, Legacy Systeme als Schicht zu Kapseln und über neue Schnittstellen erreichbar zu machen. Dadurch ergibt sich eine erhöhte Sicherheit und Usability, allerdings aber auch durch die Abstrahierung ein größerer Overhead und größere Latenzzeiten durch die Kommunikation über mehrere Schichten. Als einziges optionales Prinzip bei REST bietet Code on Demand die Möglichkeit über die API ausführbaren Code an den Client zu übermitteln bzw. nachzuladen. Dies gibt die Möglichkeit, die Funktion von einem Client unabhängig von seinem eigenen Code zu verändern bzw. zu erweitern.
Fazit
Zusammenfassend kann gesagt werden, dass es auch in Zukunft nicht den einen Kommunikationsstandard über alle Ebenen geben wird, sich die Vielfalt aber stark reduzieren wird. Am ehesten hätte OPC UA das Potential eine vertikale und horizontale Kommunikation auf und über alle Ebenen zu ermöglichen. Allerdings stellt OPC UA für ein solches Szenario auch gewisse Anforderungen an die Hardware in Form von Speicher, Rechenleistung oder auch Krypto-Chips, die von aktuellen Embedded-Geräten meist noch nicht erfüllt werden können. Auch bezüglich TSN ist aktuell noch nicht genau absehbar, wann und in welcher Form OPC UA auf der Feldebene als Echtzeitbus eingesetzt werden kann. Aktuell und über die nächsten Jahre werden auf der Feldebene noch die heterogenen Industrial-Ethernet-Feldbussen dominieren, da hier auch der Investitionszyklus von ca. 15 Jahren bei Maschinen und Anlagen berücksichtigt werden muss, in dem bestehende Anlagen Schrittweise durch neue Anlagen ersetzt werden. Hier ist es eher wahrscheinlich, dass OPC UA als einheitliche Ethernet Schnittstelle zur EDGE zum Tragen kommt, um nicht jedes Protokoll für jedes Gerät anbinden zu müssen.
Aber auch im Bereich der Cloud Kommunikation haben sich Publish/Subscribe-Protokolle wie MQTT oder AMQP Datenaustausch über REST APIs inzwischen als quasi Standard für etliche Applikationen etabliert, was eine kurzfristige Ablösung unwahrscheinlich macht. Basierend auf dieser Situation und den gegebenen Randbedingungen scheint die nachfolgend beschriebene Kommunikationsarchitektur als wahrscheinlich für die Zukunft: Daten von Feldgeräten werden unabhängig vom Industrial-Ethernet-Feldbus über OPC UA oder alternativ auch direkt über den jeweiligen Industrial-Ethernet-Feldbus an die Edge übertragen. Dort werden die ankommenden Daten über Software-Adapter in die nötigen Internet-Protokolle wie MQTT oder AMQP umgesetzt oder direkt mittels einer REST API übergeben. Welcher Weg hier exakt zum Einsatz kommt hängt hier stark damit zusammen, wohin die Daten übermittelt werden bzw. in welchem IIoT-Ökosystem gearbeitet wird. Innerhalb des Cloud-Levels ist aktuell ein Datenaustauschs via REST API am wahrscheinlichsten. Auf Seiten der Übertragung kommen somit auf den unterschiedlichen Schichten auch zukünftig unterschiedliche Technologien zum Einsatz, innerhalb der Ebenen gibt es aber eine stärkere Standardisierung. Beim Datenformat hingegen zeichnet sich eine stärkere Standardisierung über alle Ebenen hinweg ab. Hier hat aktuell die von OPC UA definierte semantische Datenbeschreibung in JSON das Potenzial der durchgehende Quasi-Standard zu werden.