Moderne Kommunikationsformen mit REST API
Machine-to-Machine-Kommunikation rationalisiert Arbeitsabläufe und steigert die Produktivität
Die Kommunikation im beruflichen Alltag läuft immer häufiger über moderne Social Media-Systeme. Dazu gehören Instant Messaging, Chats, Mikroblogging mit Werkzeugen wie Skype for Business, IBM Sametime, Cisco Jabber, WhatsApp, Slack, Microsoft Teams und viele weitere. Neben diesen Kommunikationsformen zwischen Menschen, haben sich auch die Kommunikationsformen zwischen den Softwaresystemen gewandelt (Maschine-zu-Maschine Kommunikation). Lief dies in der Vergangenheit hauptsächlich über Webservices, so benutzen moderne Software-Systeme immer häufiger RESTful-Schnittstellen, um Daten zwischen Software-Systemen auszutauschen und Funktionalitäten in anderen Systemen anzustoßen. Ein Beispiel ist die Anzeige von Bildern anhand der Längen- und Breitengrad-Angaben auf Instagram.
Im technischen Bereich werden RESTful-Schnittstellen auch als „REST API“ bezeichnet. REST APis haben seit 2005 immer mehr an Bedeutung gegenüber anderen Varianten wie SOAP gewonnen, wie dies in einem Blogbeitrag von Guy Levin beschrieben ist.
Was ist REST API und wozu wird sie verwendet?
REST API bedeutet „Representational State Transfer“– „Application Programming Interface“.
Eine REST API kann man sich so ähnlich wie eine Webseite vorstellen. Von einem Nutzer „Client“ wird ein Aufruf „Call“ getätigt und die Webseite „Server“ gibt dem Nutzer anschließend eine Rückantwort. Die REST API wird also dafür gebraucht, um eine Kommunikation zwischen einem „Server“ und einem „Client“ zu ermöglichen. Besteht Bedarf, so können die Schritte einer REST API auch manuell nachgestellt werden. Eine REST API ist jedoch generell dazu ausgelegt, mehrere tausende Aufgaben der gleichen Art, z.B. den Versuch sich auf einer Seite einzuloggen, in sehr kurzer Zeit abzuarbeiten. Dementsprechend ist auch eine REST API effizienter als eine manuelle Vorgehensweise.
Anhand des Bildes, soll nun der typische Aufbau und die Zusammensetzung eines typischen REST API-Aufrufs erklärt werden. Das Bild zeigt uns hierbei, wie ein solcher Aufruf aufgebaut ist. Zugegeben wirkt das Ganze für das ungeschulte Auge erst einmal suspekt. Der visuelle Aufbau kann sich von Schnittstelle zu Schnittstelle ändern, aber das Prinzip dahinter bleibt dasselbe.
Wichtige Parameter
Beim Aufbau eines REST API-Aufrufs wird zwischen bestimmten Parametern unterschieden. Die Parameter können Kopfdaten „Headers“, Rumpfdaten „Body“, Aufruftyp „POST oder GET“ oder Formatierungstypen „fullres oder minres“ sein.
Bei einem REST API-Aufruf wird je nach Aufruftyp unterschieden, welche Daten später zurückgeliefert werden. Mit einem „POST“ Aufruftyp möchte man bezwecken, dass auf dem Server, der über die URL angegeben wird, bestimmte Inhalte übertragen werden sollen. Das Bild zeigt z.B. einen Aufruf, der einen Server kontaktiert und sich versucht, sich auf ihm einzuloggen. Das kann daran erkannt werden, dass nach der URL-Angabe zum Server „https://server.gbs.com“ und der Angabe zur RESTful-Schnittstelle „/api/workflowmanager/“, die REST API-Methode „/common/login“ aufgerufen wird. In welchem Format die Daten zurückkommen, wird im „resultformat=“ Teil beschrieben.
Zusätzlich zu den oben beschriebenen Aspekten sollte noch beachtet werden, ob für den REST API-Aufruf bestimmte Kopfdaten benötigt werden. Häufiger werden bestimmte Kopfdaten benötigt, welche dann über die „Headers“ Sektion angegeben werden müssen. Wird z.B. mit einem „POST“ Aufruftyp versucht, eine andere Maschine zu kontaktieren, kann es notwendig sein, zusätzliche Informationen im Rumpf „Body“ anzugeben. Hier wird versucht, sich auf einem Server einzuloggen. Das Einloggen erfordert Benutzerdaten, um den Benutzer verifizieren zu können. Dies trifft sowohl beim manuellen Einloggen als auch beim Einloggen über einen REST API-Aufruf zu. Deswegen werden im Rumpf zusätzliche Informationen wie der Benutzername und das Benutzerkennwort benötigt. Je nachdem wie die RESTful-Schnittstelle des Servers eingestellt ist, könnten weitere Informationen benötigt werden.
Zusammengefasst braucht ein REST API-Aufruf also einen Aufruftyp (POST, GET, PUT, PATCH), eine Zieladresse (URL mit bestimmten Parametern) und bestimmte Informationen, die in Kopf- („Headers“) und Rumpfdaten („Body“) unterteilt sind.
Swagger
Genauso wie sich die Kommunikation zwischen Menschen verändert hat, so hat sich diese auch zwischen Maschinen verändert. Für die zwischenmenschliche Kommunikation sind mit der Zeit Werkzeuge dazugekommen, durch deren Hilfe es möglich ist, auf größere Distanzen mit anderen Menschen in Kontakt zu bleiben. Swagger ist ein ebenso hilfreiches Werkzeug, welches der Kommunikation zwischen Maschinen und Menschen dient. Swagger lässt sich in einer Webseite einpflegen und besitzt eine relativ einfache Oberfläche, die es dem Anwender der REST API-Methoden ermöglicht, diese schnell und einfach zu verwenden. Die URLs zu Swagger variieren von Unternehmen zu Unternehmen. Ein Beispiel einer möglichen URL zu Swagger kann wie folgt aussehen: „href=“https://server.gbs.com/api/workflowmanager/“
Popularität, Erweiterungsmöglichkeit, Dokumentierbarkeit und die einfache Handhabung von Swagger optimiert die Verwendung im Alltag bei der Entwicklung von Schnittstellen zwischen Software-Systemen. Durch die einfache Struktur und die meist gut dokumentierten REST API-Methoden, ermöglicht Swagger Anwendern mit geringen bis gar keinen Erfahrungen in der Programmierung, erfolgreich einen REST API-Aufruf zu verwenden.
Diana Maltseva, eine Bloggerin aus Minsk, schreibt in ihrem Blogbeitrag, dass die Benutzung von Swagger der beste Weg sei, Entwicklungen und wertvolle Informationen mit anderen Softwareentwicklern zu teilen.
Auch aus einer Statistik in der Präsentation der Swagger-Entwickler geht hervor, dass Swagger gegenüber anderen Hilfswerkzeugen mehr Ansehen genießt. Die Präsentation kann hier angesehen werden.
Swagger in GBS-Lösungen integriert
Bei GBS nutzen wir Swagger und haben es in unseren Produkten wie die iQ.Suite, GBS Workflow Manager oder dem GBS Retirement Manager eingebunden. Dort können schnell neue REST API-Methoden hinzugefügt, dokumentiert oder genutzt werden. Durch die oben bereits erwähnte Oberfläche, lässt es sich leicht durch die einzelnen Abschnitte navigieren und bei Bedarf auch schnell bestimmte REST API-Methoden ausführen. Durch die gute Struktur und der Möglichkeit Swagger an die eigenen Bedürfnisse anzupassen, kann sich Swagger bestens in die GBS-Produkte integrieren lassen. Das Aussehen der Oberfläche sieht beim GBS Workflow Manager aus, wie im linken Bild veranschaulicht ist.
Sollen REST API-Methoden über Swagger getestet werden, so sollte sich auf die Swagger-Webseite eingewählt und anschließend die gewünschten Methoden aufgeklappt werden. Zum Testen werden bestimmte Informationen in den einzelnen REST API-Methoden benötigt, die aber auch in Swagger angezeigt werden. Das Aussehen einer aufgeklappten REST API-Methode kann beispielhaft dem beistehenden Bild entnommen werden.
Um die Methode zu testen, sollten die oben geforderten Informationen übergeben und anschließend auf den unten stehenden Knopf „try it out!“ geklickt werden. Wurde der Knopf gedrückt, so wird sofort eine Statusmeldung angezeigt, ob die Methode erfolgreich ausgeführt werden konnte oder nicht. Außerdem kann eine Legende der einzelnen Statuscodes angezeigt werden, dies hängt jedoch davon ab wie die Oberfläche von Swagger angepasst wurde. Bei einer Methode des GBS Workflow Manager kann dies so wie in nebenstehender Abbildung aussehen.
Übersicht über Prozessinstanzen
Als Anwendungsfall kann z.B. eine Excel-Tabelle fungieren, mit der Daten aus dem GBS Workflow Manager geholt und mit den Excel-typischen Funktionen als Pivot-Tabelle oder Diagramm veranschaulicht werden können.
Damit der Anwender keine programmatischen Änderungen vornehmen muss, bietet es sich an, in der Excel-Tabelle einen Konfigurationsbereich zu integrieren. In diesem Anwendungsfall (Dashboard) sollen Daten aus bestehenden Systemen, z.B. einem Cloud-System abgeholt werden. Hierfür werden vom Dashboard bestimmte Informationen benötigt, welche in einem Konfigurationsbereich eingetragen werden. In der beistehenden Abbildung wird der Konfigurationsbereich gezeigt, der in zwei Abschnitte unterteilt ist. Der rechte Abschnitt besteht aus mehreren Zeilen, die bestimmte Informationen verlangen. Wurden alle Informationen übergeben, so kann im linken Abschnitt des Konfigurationsbereichs durch den Knopf „Importiere Daten“ der REST API Aufruf gestartet werden.
Wird der REST API-Aufruf gestartet, überprüft dieser zuerst, ob alle benötigten Informationen übergeben wurden. Fehlt eine der Informationen, wird der Anwender dazu aufgefordert diese nachzutragen. Sind bestimmte Informationen, wie beispielsweise die URL fehlerhaft, so kommt es zu einer Fehlermeldung, die anschließend dem Anwender angezeigt wird.
Die geholten Daten werden unterhalb des Abschnitts „Daten“ spezifiziert. Um diese passend einzustellen, wird jedoch Erfahrung in der Programmierung oder Hintergrundwissen benötigt, weswegen dies genauer in einem GBS Knowledge Base-Beitrag zum Thema erklärt wird.
Wurden alle Einstellungen getroffen und der REST API-Aufruf ausgeführt, werden als Resultat die gewünschten Daten unterhalb des Bereichs „Daten“ eingetragen. Falls es vom Anwender gewünscht ist, können diese Daten nun in Pivot-Tabellen und -Diagrammen visualisiert werden. Die Diagramme können in den Pivot-Tabellen nach bestimmten Kriterien gefiltert werden, um bestimmte Sachverhalte abzubilden. Nach einmaligem Ausführen des REST API-Aufrufs, werden die Daten aus den Pivot-Tabellen und -Diagrammen automatisch aktuell gehalten.
Alle Informationen auf einen Blick
In der Abbildung ist eine mögliche Visualisierung zu sehen.
Man erhält mit einem Blick alle Informationen grafisch visualisiert angezeigt. Durch die Visualisierung in Microsoft Excel wird auch gewährleistet, dass die Diagramme schnell in Präsentationen eingefügt werden können und damit eine aussagekräftige Übersicht ihre Präsentation unterstützt. Unternehmen, die sich z.B. mit Kalkulationen beschäftigen, können mit solch einer Excel-Tabelle mit Leichtigkeit bestimmte Posten einer Kalkulation herausholen und anschließend als Grafik darstellen.
Unternehmen oder Abteilungen, die prozessorientiert am selben Dokument arbeiten, können so z.B. durch die Angabe eines Status eine einfache grafische Übersicht erhalten, die anzeigt, welche Dokumente sich in welchem Status befinden und wie viele Dokumente einen bestimmten Status besitzen.
Fazit
Zusammenfassend lässt sich also sagen, dass die Verwendung einer RESTful-Schnittstelle mithilfe von Swagger eine gute Lösung für verschiedenste prozessorientierte Verarbeitungen darstellt. Auf dieser Basis kann der Anwender relativ schnell und einfach eine grafische und aussagekräftige Lösung erstellen.
Der Beitrag M2M – Wenn Maschinen miteinander kommunizieren erschien zuerst auf GBS - Der Blog rund um Security, Collaboration & Co.
Was passiert nun am 4. und 5. Dezember in Stuttgart? Das Acoustic Launch Event beginnt um 15:30 Uhr im Mercedes-Benz Museum. Dort wird Natalie Lamb, designierte EMEA-Chefin für Acoustic, zusammen mit Jay Henderson, Senior Vice President für Produkt Management, die Besucher begrüßen. Jay stellt dann die Produktstrategie von Acoustic vor, das die größte unabhängige Marketing Cloud mit einem offenen, lebendigen Ökosystem werden will. Was gerade die Trends und Themen im digitalen Marketing sind, behandelt dann Martin Meyer-Gossner, der auch als Moderator durch die Veranstaltung führt.
Genau an diesen Stellen gilt es dann auch, das Thema künstliche Intelligenz zu hinterfragen. Was kann KI im Angesicht der DSGVO in der Auswertung der Daten für das Marketing wirklich leisten? Wir haben sicher genug Stoff für eine interessante Diskussion mit den Referenten und dem Publikum. Es haben sich ja schon wortgewaltige Experten mit pointierter Meinung angemeldet. Und wir sind auch noch auf der Suche nach ein oder zwei Sprechern von Unternehmen, die zu den Marketingtrends ihre Meinung haben. Rund um das Mercedes-Benz Museum und in Stuttgart sitzen ja einige namhafte Unternehmen.
Durch den Tag führen Avril Couper und Mateusz Urban und Kolleginnen aus der Entwicklung werden direkt vor Ort sein, denn in Böblingen sitzen einige der Developer von (bald) Acoustic, die insbesondere an dem Acoustic Content-Produkt arbeiten. Nachdem Jay Henderson an diesem Tag technisch tiefer in die Roadmap eingestiegen ist, wird Thomas Stober aus dem Labor Acoustic Content detailliert unter dem Titel „Content as a Service and Web Sites in a Omnichannel World“ vorstellen- bestimmt ganz besonders interessant, direkt von der Entwicklung mehr über die Pläne zu erfahren.
