Bevor wir konkret auf die REST Schnittstelle, auch Application Programming Interface oder kurz API genannt, eingehen, hier ein beispielhafter Erklärungsversuch, wieso solche Schnittstellen so praktisch sind: Da Schnittstellen nach dem Prinzip von “Plug and Play” funktionieren, eignet sich hier der Vergleich mit dem Stromanschluss recht gut. Stellen Sie sich vor, Sie müssten, bevor Sie eine Tasse Kaffe machen können, sich zuerst mit der ganzen Elektrotechnik auseinandersetzen, um fliessenden Strom vom Energiehersteller zu Ihnen nach Hause kriegen zu können.
Es ist offensichtlich, dass dies aus diversen Gründen nicht wirklich Sinn ergeben würde. Das möglicherweise fehlende Know-How und die sehr wahrscheinliche Ineffizienz im Prozess sind zwei naheliegende Begründungen. Stattdessen schliessen Sie doch einfach die Kaffeemaschine an der Steckdose an und los geht’s. So ziemlich identisch sind Schnittstellen zu verstehen. Sprich, Sie erhalten somit den fixfertigen Zugang zu einer Funktionalität, die Sie für irgendetwas gebrauchen können und nicht etwas zuerst selbst noch bauen müssen.
Schnittstellen sind also eine sehr praktische Art eines codebasierten Konstruktes, die uns erlauben, Systeme und Funktionalitäten einfacher und wesentlich schneller zu bauen. Sie reduzieren die Komplexität des Source Codes und stellen uns eine einfach anwendbare Syntax zur Ansteuerung eines Programms zur Verfügung, wodurch wir die Kommunikation zwischen zwei unabhängigen Softwarekomponenten herstellen können.
Allgemeine Schnittstellarten
Basierend auf der Art wie Systeme und Software miteinander interagieren und die Applikationsarchitektur bilden, gibt es verschiedene Schnittstellen für Hardware, Betriebssysteme, Datenstrukturen, Web Services, etc. Handelt es sich um softwarespezifische Schnittstellen, sind diese oftmals nur über spezielle Programmiersprachen implementierbar. Zudem haben sie nicht selten eine eigene Syntax und Funktionen, was fürs effiziente Handling entweder spezifische Kompetenzen oder Kapazität zum Einlesen voraussetzt. Dann gibts auch noch dateibasierte Schnittstellen, die Dateien in bestimmten Formaten austauschen, wodurch ein System aber langsam und fehleranfällig wird. Wenns um webbasierte Schnittstellen geht, spricht man in der Regel je nach Datantransferformat im Request-Respond Messaging von SOAP (Simple Object Access Protocol), RPC (Remote Procedure Call) oder eben von der REST API. Letztere ist eine der bekannteren. Und diese schauen wir uns jetzt nachstehend genauer an.
Die REST API
Die REST (Representational State Transfer) API ist eine der wohl simpelsten Architekturen, wie Schnittstellen designt werden können. Sie hat zum Ziel die Verbindung zweier Webapplikationen durch die Standardisierung der Modalität radikal zu vereinfachen. Representational State Transfer heisst sie, da in der Kommunikation zwischen den Applikationen Informationen über den Zustand der Server-Ressourcen in beispielsweise JSON-, XML- oder HTML-Format geteilt beziehungsweise repräsentiert werden. Dabei erlaubt die REST API einem Client, also zum Beispiel Ihnen, Aktionen wie Ressourcen zu lesen (GET), neue Objekte zu erstellen (POST), Informationen zu aktualisieren/editieren (PUT) oder diese zu löschen (DELETE). Die entsprechenden Befehle schickt der Client einfach über HTTP. Neben dieser einheitlichen Schnittstelle gibt es noch weitere Restriktionen, welche eingehalten werden müssen, um auch wirklich dem REST-Format zu entsprechen (Client und Server Separation, stateless, geschichtetes System und cacheable). Diese behandeln wir hier aber nicht weiter.
Vorteile
Wieso wir uns nun bei Parashift dafür entschieden haben, eine REST API für die Integration unserer Produktes zu entwickeln, hat einerseits mit den allgemeinen Vorteilen von REST APIs zu tun:
- Vereinfachtes standardisiertes Format, wodurch Implementierungen stark vereinfacht und beschleunigt werden
- Pflegeleichtigkeit im Unterhalt
- Server und Client Separation, was grosse Flexibilität und Möglichkeiten zur individuellen Skalierung schafft
- Höhere Ressourceneffizienz, da der Status der Kommunikation zwischen Server und Client nicht gespeichert werden muss
- Prozessinstanzen werden jeweils explizit erstellt
- Statelessness beziehungsweise Zustandslosigkeit ermöglicht wesentlich schnellere Recovery-Prozesse bei Fehlern und erhöht die Zuverlässigkeit
- Adaptierbarkeit auf Syntax beziehungsweise andere Systeme
Anderseits aber auch aufgrund dessen, dass wir über die URL unseren Kunden WebHooks zur Verfügung stellen können. Darüber senden wir ihnen Notifications zur Information über den Plattform Status und sie können sich das regelmässig Senden von Call-Requests ersparen. Das heisst, wir informieren beispielsweise bei der Full-Extraction Methode, wenn die Prozesse der Nachkontrolle abgeschlossen sind und die korrigieren Ergebnisse bereit sind beziehungsweise für die weiterführenden Workflows abgeholt werden können. Dadurch ergibt sich eine ideale Integrationsmöglichkeit in bestehende gut getaktete Systeme und Geschäftsprozesse.
