Was ist eine API?

Eine API (Application Programming Interface) ist eine Sammlung von Protokollen, Routinen und Tools zur Interaktion zwischen verschiedenen Softwareanwendungen. Vereinfacht ausgedrückt, ermöglicht eine API die Kommunikation zwischen zwei Softwareanwendungen, indem sie dem Entwickler die Möglichkeit bietet, bestimmte Funktionen oder Daten einer Anwendung zu verwenden, ohne sich um deren interne Implementierung kümmern zu müssen.

Funktionsweise von APIs

APIs ermöglichen die Kommunikation zwischen Anwendungen, indem sie standardisierte Anfragen und Antworten verwenden. In der Regel bezeichnet man eine Anwendung, die eine API bereitstellt, als Server. Die Anwendung, die die API nutzt, bezeichnet man als Client. Der Client sendet eine Anfrage an den Server, der diese Anfrage bearbeitet und daraufhin eine Antwort zurücksendet.

Die Kommunikation erfolgt meist über das https-Protokoll und basiert auf einem Request-Response-Modell. Eine API-Anfrage enthält normalerweise Informationen wie die gewünschte Aktion, die zu verwendenden Daten und den Authentifizierungsschlüssel. Die Antwort beinhaltet dann das Ergebnis der Aktion, zusammen mit den angeforderten Daten, falls vorhanden.

Arten von APIs

Es gibt verschiedene Arten von APIs, je nach Zugriffsbeschränkungen und Anwendungsbereich. Hier sind einige der gebräuchlichsten Typen:

Öffentliche APIs: Auch als externe oder offene APIs bekannt, sind APIs, die für die Öffentlichkeit zugänglich sind. Entwickler können sie nutzen, um angebotene Dienste in ihre Anwendungen zu integrieren.

Private APIs: Diese APIs sind nur für einen bestimmten Entwicklerkreis oder innerhalb eines Unternehmens zugänglich. Entwickler verwenden sie, um interne Prozesse und Dienstleistungen zu unterstützen.

Partner-APIs: Partner-APIs sind für eine ausgewählte Gruppe von Entwicklern oder Unternehmen zugänglich, die eine Partnerschaft oder Geschäftsvereinbarung mit dem API-Anbieter eingegangen sind.

API-Protokolle und Datenformate

APIs nutzen verschiedene Protokolle und Datenformate, um Anfragen und Antworten zu strukturieren. Die gebräuchlichsten sind:

REST (Representational State Transfer): Ein Architekturstil, der auf der Verwendung von standardisierten https-Anfragen und Antworten basiert. REST-APIs sind ressourcenorientiert und relativ leicht verständlich. Man verwendet sie häufig mit JSON (JavaScript Object Notation) als Datenformat.

SOAP (Simple Object Access Protocol): Ein älteres Protokoll, das auf XML-basierten Nachrichten beruht und strenge Regeln für die Kommunikation vorschreibt. SOAP-APIs sind tendenziell komplexer als REST APIs, bieten jedoch eine höhere Sicherheit und formelle Spezifikationen.

GraphQL: Eine relativ neue API-Technologie, von Facebook. Im Gegensatz zu REST und SOAP ermöglicht GraphQL eine flexiblere Datenabfrage, indem der Client genau die benötigten Informationen anfordern kann. GraphQL verwendet eine eigene Abfragesprache und unterstützt sowohl Lese- als auch Schreiboperationen.

gRPC: Ein von Google entwickeltes API-Framework, das auf Protocol Buffers, als binäres Datenformat setzt und für hohe Leistungsfähigkeit und Skalierbarkeit optimiert ist. gRPC eignet sich besonders für Mikroservices und hochperformante Anwendungen. Ich gehe davon aus, dass ich darüber in naher Zukunft einen separaten Beitrag schreibe.

API-Authentifizierung und -Sicherheit

Um den Zugriff auf APIs zu kontrollieren und deren Sicherheit zu gewährleisten, kann man verschiedene Authentifizierungs- und Autorisierungsmechanismen einsetzen. 

Einige der gängigen Methoden sind:

API-Schlüssel: Ein einfacher und weit verbreiteter Ansatz, bei dem der Entwickler einen eindeutigen Schlüssel erhält, den man bei jeder API-Anfrage übermittelt, um den Zugriff zu autorisieren.

OAuth: Ein offener Standard für Authentifizierung und Autorisierung, der es ermöglicht, Anwendungen den Zugriff auf Benutzerdaten von Drittanbietern zu gewähren, ohne dass die Anwendung das Passwort des Benutzers kennen muss. Sozialen Netzwerke und große Webdienste wie Google und Facebook nutzen häufig OAuth.

JWT (JSON Web Tokens): Eine kompakte, selbstständige Methode zur sicheren Übertragung von Informationen zwischen Parteien in Form von Objekten. Man nutzt JWTs häufig in Kombination mit OAuth und anderen Authentifizierungsschemata.

Best Practices bei der Verwendung von APIs

Die erfolgreiche Nutzung von APIs erfordert einige Best Practices, um sicherzustellen, dass Anwendungen effizient und sicher arbeiten:

Dokumentation: Eine gut dokumentierte API erleichtert Entwicklern das Verständnis und die Integration der API in ihre Anwendungen.

Fehlerbehandlung: Eine robuste Fehlerbehandlung ist entscheidend, um sicherzustellen, dass Anwendungen auch bei unerwarteten Fehlern oder Ausfällen der API korrekt funktionieren.

Ressourcenmanagement: Bei der Verwendung von APIs ist es wichtig, auf Ressourcenmanagement zu achten. Dies erreichet man beispielsweise, indem man Ratenbegrenzungen (Rate Limiting) einhält, um die Anzahl der Anfragen pro Zeiteinheit zu begrenzen und die Belastung des API-Servers zu reduzieren.

Sicherheit: Bei der Arbeit mit APIs sollte man auf die Sicherheit der Anwendung und der API achten. Durch die Verwendung von Verschlüsselungstechniken und sicheren Authentifizierungsmethoden lässt sich dies relativ einfach realisieren.

Zukünftige Trends bei APIs:

APIs gewinnen weiterhin an Bedeutung, da sich die Technologielandschaft weiterentwickelt. Um neue Anforderungen und Herausforderungen zu bewältigen, müssen sich auch die APIs weiterentwickeln.

Einige zukünftige Trends bei APIs sind:

Hypermedia-APIs: Ein aufkommender Trend im Bereich der REST APIs ist die Verwendung von Hypermedia-Elementen zur Dynamisierung der API-Kommunikation. Hypermedia-APIs stellen Links und Aktionen in den API-Antworten bereit, um den Client zur Verfügung stehende Funktionen und Ressourcen dynamisch zu erkennen. Dadurch kann man die Kopplung zwischen Client und Server reduzieren.

API-Orchestrierung: Mit der zunehmenden Verbreitung von Mikroservices und verteilten Systemen gewinnen die API-Orchestrierung und -Aggregationen immer mehr an Bedeutung, um eine effiziente Kommunikation und Integration zwischen verschiedenen Diensten zu gewährleisten.

Edge-Computing und APIs: Mit der zunehmenden Verbreitung von IoT-Geräten und Edge-Computing-Technologien ist die Rolle von APIs bei der Bereitstellung von Echtzeitdaten und Funktionen für Geräte am Netzwerkrand essenziell.

KI-gestützte APIs: Integration von künstlicher Intelligenz und maschinellem Lernen, um leistungsfähige Funktionen wie Spracherkennung, Computer Vision bzw. Bildanalyse und datengesteuerte Vorhersagen bereitzustellen.

API-Sicherheit und Datenschutz: Angesichts der wachsenden Besorgnis über Datensicherheit und Datenschutz nimmt man APIs zunehmend unter die Lupe, um sicherzustellen, dass sie den geltenden Datenschutzbestimmungen entsprechen und angemessene Sicherheitsmaßnahmen implementieren.

Fazit

APIs sind ein grundlegendes Element moderner Softwareentwicklung und ermöglichen eine effiziente und skalierbare Kommunikation zwischen verschiedenen Anwendungen und Diensten. Durch das Verständnis der verschiedenen API-Typen, Protokolle, Datenformate und Best Practices können Entwickler ihre Anwendungen effektiv erweitern und mit externen Diensten integrieren. Indem man auf API-Dokumentation, Fehlerbehandlung, Ressourcenmanagement und Sicherheit achtet, kann man sicherstellen, dass die API-Integration erfolgreich ist und zur Verbesserung der Gesamtanwendung beiträgt.

Der Beitrag API – Nahtlose Verbindungen für Innovationen erschien zuerst auf CEOsBay.

Kurze Zeitreise

Wie bereits zu Beginn erwähnt, geht die Entstehung von OpenAPI auf die Einführung der Swagger-Spezifikation zurück, die ursprünglich Tony Tam im Jahr 2010 entwickelt hat. Swagger entstand aus dem Bedürfnis heraus, eine standardisierte und einfache Möglichkeit zur Beschreibung, Dokumentation und Interaktion mit RESTful-APIs zu schaffen. Die Spezifikation und die damit verbundenen Tools gewannen schnell an Popularität in der Entwicklergemeinschaft.

Im Jahr 2015 wurde die OpenAPI-Initiative (OAI) ins Leben gerufen, um die Weiterentwicklung der Swagger-Spezifikation in einer kollaborativen und branchenübergreifenden Umgebung voranzutreiben. Die OAI wurde von Unternehmen wie Google, IBM, Microsoft, SmartBear Software und weiteren Technologieunternehmen unterstützt.

In der Folge hat die Swagger-Spezifikation unter der Leitung der OpenAPI-Initiative eine Weiterentwicklung erfahren den neuen Namen OpenAPI erhalten. Dies trug dazu bei, die gemeinschaftliche Natur des Projekts widerzuspiegeln. Die Veröffentlichung der ersten Version der OpenAPI-Spezifikation (OpenAPI 2.0) fand im September 2016 statt und basierte auf der damaligen Swagger 2.0-Spezifikation.

Seitdem hat es sich als Standard für die Beschreibung von RESTful-APIs etabliert und ist durch kontinuierliche Weiterentwicklung und Zusammenarbeit in der Industrie gewachsen. Die neueren Versionen brachten eine Reihe von Verbesserungen und neue Funktionen im Vergleich zu OpenAPI 2.0. Darunter eine bessere Unterstützung für JSON-Schema, verbesserte Modularität und erweiterte Möglichkeiten zur Beschreibung von API-Endpunkten sowie Datenmodellen.

Wie funktioniert OpenAPI?

Grundlagen

OpenAPI definiert eine standardisierte, sprachagnostische Schnittstelle, um RESTful-APIs auf eine maschinenlesbare Weise zu beschreiben. Diese Beschreibung enthält Informationen über die verfügbaren Endpunkte, die unterstützten Operationen (wie GET, POST, PUT, DELETE) (Siehe auch CRUD), die möglichen Rückgabewerte und viele weitere Details. Es verwendet das YAML- oder JSON-Format, um diese Beschreibungen auf leicht verständliche und bearbeitbare Weise zu präsentieren.

Vorteile

Standardisierung:

Es bietet eine einheitliche und standardisierte Methode zur Beschreibung von RESTful-APIs. Dadurch gewährleistet bzw. verbessert man die Interoperabilität zwischen verschiedenen Systemen und Technologien.

Dokumentation:

OpenAPI-Dokumente dienen als lebendige Dokumentation der API, die immer auf dem neuesten Stand ist. Dies erleichtert die Zusammenarbeit zwischen verschiedenen Teams und reduziert die Wahrscheinlichkeit von Fehlern und Inkonsistenzen.

Generierung von Code und Client-Bibliotheken:

Durch die maschinenlesbare Natur der Spezifikation können Entwickler automatisch Code-Stubs, Server-Implementierungen und Client-Bibliotheken in verschiedenen Programmiersprachen generieren.

API-Design und -Validierung:

Es ermöglicht Entwicklern, ihre API-Designs frühzeitig zu validieren und Inkonsistenzen zu identifizieren, bevor sie in die Implementierung einfließen.

Interaktive API-Explorer:

Man kann OpenAPI-Dokumente in interaktive API-Explorer, wie z. B. Swagger UI, importieren, um APIs auf benutzerfreundliche Weise zu erkunden und zu testen.

Ökosystem

Das Ökosystem umfasst zahlreiche Tools und Lösungen, die Entwickler bei der Arbeit mit der Spezifikation unterstützen. Einige der bekanntesten Tools sind:

Swagger:

Swagger ist eine Sammlung von Tools, die Entwicklern helfen, ihre APIs zu entwerfen, zu dokumentieren und zu testen. Dazu gehören unter anderem Swagger Editor, Swagger Codegen und Swagger UI.

ReDoc:

ReDoc ist eine Open-Source-Lösung zur Erstellung von API-Dokumentationen auf Basis von OpenAPI-Dokumenten. Es bietet eine übersichtliche und ansprechende Darstellung der API-Dokumentation, die für Endbenutzer leicht zugänglich ist.

Postman:

Postman ist ein weit verbreitetes API-Entwicklungstool, das die Unterstützung für OpenAPI-Spezifikationen bietet. Es ermöglicht Entwicklern, APIs zu entwerfen, zu testen, zu dokumentieren und zu überwachen, indem sie die OpenAPI-Dokumente importieren und mit den integrierten Tools interagieren.

API-Lebenszyklus

Der Einsatz von OpenAPI erstreckt sich über den gesamten API-Lebenszyklus:

Planung:

Entwickler können OpenAPI verwenden, um das API-Design zu skizzieren und Einigkeit über die Funktionsweise und Struktur der API zu erzielen.

Entwicklung:

Mit automatisch generierten Code-Stubs und Client-Bibliotheken auf Basis der Spezifikation können Entwickler schnell und effizient an der Implementierung arbeiten.

Testen:

Es ermöglicht das einfache Erstellen von Testfällen und das automatisierte Testen von APIs auf Kompatibilität und Konformität mit der Spezifikation.

Dokumentation:

Die lebendige Dokumentation auf Grundlage von OpenAPI-Dokumenten stellt sicher, dass API-Benutzer immer auf dem neuesten Stand der API-Funktionalität sind.

Deployment:

Man kann OpenAPI-Dokumente für die automatische Bereitstellung und Konfiguration von APIs auf verschiedenen Plattformen und Umgebungen verwenden.

Überwachung und Wartung:

Damit generierte Tests und Überwachungstools kann man die API-Performance überwachen und Wartungsmaßnahmen effizient durchgeführen.

Alternative API-Spezifikationen

Daneben gibt es noch andere API-Spezifikationen wie RAML (RESTful API Modeling Language) und API Blueprint. Alle drei Spezifikationen haben ähnliche Zielsetzungen, unterscheiden sich jedoch in Syntax, Tool-Unterstützung und Popularität. OpenAPI ist derzeit die am weitesten verbreitete Spezifikation und eine Vielzahl von Organisationen sowie Entwickler bevorzugen es.

Fazit:

OpenAPI ist eine leistungsstarke und flexible Spezifikation, die Entwicklern hilft, RESTful-APIs zu entwerfen, zu erstellen und zu dokumentieren. Es bietet eine standardisierte, sprachunabhängige Schnittstelle und unterstützt den gesamten API-Lebenszyklus von der Planung bis zur Überwachung. Mit einem reichhaltigen Ökosystem an Tools und Lösungen hat es seine Stellung als führende API-Spezifikation im heutigen schnelllebigen Technologieumfeld gefestigt.

Der Beitrag OpenAPI – Die Brücke für nahtlose Kommunikation und effiziente Integration von Web-Services erschien zuerst auf CEOsBay.

Es handelt sich dabei also nicht um den fast gleichnamigen fiktiven Supercomputer HAL 9000. Den man aus dem Science-Fiction-Roman „2001: Odyssee im Weltraum“ von Arthur C. Clarke oder dem gleichnamigen Film von Stanley Kubrick aus dem Jahr 1968 kennt ;).

Es steht für „Hypertext Application Language“ und basiert auf dem HATEOAS (Hypermedia as the Engine of Application State)-Konzept. Das Ziel von HAL ist es, eine einheitliche Methode zum Beschreiben von APIs bereitzustellen. Gleichzeitig soll sie die Interoperabilität zwischen verschiedenen Systemen und Plattformen verbessern.

Im Wesentlichen besteht ein HAL-Dokument aus zwei Teilen: Ressourcen und Links. Eine Ressource ist eine Datenstruktur, die Informationen über eine bestimmte Entität enthält. Links sind Beziehungen zwischen Ressourcen, die es einem Client ermöglichen, auf eine andere Ressource zuzugreifen. Ein Link enthält normalerweise einen URI (Uniform Resource Identifier). Dieser hat eine eindeutige Adresse für eine Ressource, die sie bereitstellt und einen Relationstyp. Dieser beschreibt, welche Beziehung die verknüpfte Ressource zur aktuellen Ressource hat.

Ein typisches HAL-Dokument ist ein simples JSON [RFC7159] und kann folgendermaßen aussehen:

{
  "_links": {
    "self": { "href": "/api/book/123" },
    "author": { "href": "/api/author/456" }
  },
  "title": "2001: Odyssee im Weltraum",
  "authorName": "Arthur C. Clarke",
  "publishedDate": "1968"
}

In diesem Beispiel enthält das HAL-Dokument eine Ressource, die Informationen über ein Buch enthält, sowie Links zu anderen Ressourcen. Beispielsweise dem Autor des Buches. Der Link mit dem Relationstyp „self“ gibt an, dass der Link auf die aktuelle Ressource verweist. Während der Link mit dem Relationstyp „author“ angibt, dass der Link auf den Autor des Buches verweist.

Ein wichtiger Aspekt des HAL-Formats ist, dass es HATEOAS unterstützt. Dies bedeutet, dass alle Ressourcen in einer API durch Links miteinander verbunden sind. Dadurch kann ein Client einer API eine Ressource abrufen und im Anschluss die verfügbaren Links verwenden, um weitere Aktionen auszuführen. Beispielsweise das Abrufen von verwandten Ressourcen oder das Ausführen von Aktionen auf einer Ressource. Dadurch kann man die Flexibilität und Erweiterbarkeit einer API verbessern. Weil man eben neue Ressourcen und Aktionen hinzufügen kann, ohne dass Änderungen am Client-Code erforderlich sind.

Fazit

Insgesamt ist der HAL-Standard eine nützliche Methode zur Beschreibung von APIs. Es gewährleistet eine gute Interoperabilität zwischen verschiedenen Systemen, steigert die Flexibilität und Erweiterbarkeit einer API.

Der Beitrag HAL-Standard – Effiziente Hypermedia-APIs für nahtlose Web-Service-Interaktionen und erweiterbare Systeme erschien zuerst auf CEOsBay.

Es stützt sich auf XML zur Repräsentation der Daten und auf Internet-Protokolle der Transport- und Anwendungsschicht zur Übertragung der Nachrichten. Die gängigste Kombination ist SOAP über https (Hypertext Transfer Protocol) und TCP (Transmission Control Protocol). Man kann SOAP auch über das SMTP (Simple Mail Transfer Protocol) oder JMS (Jakarta Messaging) verwenden.

Die mit der Nachricht übermittelten Nutzdaten man nicht zwingend in XML senden. Andere Formate wie Base64 oder CSV sind ebenfalls möglich. Seit Version 1.2. nutzt man die Abkürzung SOAP offiziell nicht mehr als Akronym, da es erstens (subjektiv) keineswegs einfach (Simple) ist und zweitens nicht nur dem Zugriff auf Objekte (Object Access) dient.

Kurze Zeitreise

SOAP entstand aus der Weiterentwicklung der Spezifikation für XML-RPC im Jahr 1998. Hauptverantwortlicher Software-Entwickler damals Dave Winer und seine Firma UserLand Software in engem Austausch mit Microsoft. Dave Winter ist übrigens auch für RSS 2.0 verantwortlich. Einen Beitrag über RSS findet man hier.

Im Jahr 1999 fand die Veröffentlichung der Version 1.0 von SOAP statt. Dies stellt unter Anderem den Zeitpunkt dar, an dem die Entwicklung mehr Unterstützung fand. Vor allem hat sich IBM im Jahr 2000 der Entwicklung angeschlossen, was dazu führte, dass IBM, Microsoft, DevelopMentor (Don Box) und UserLand Software (Dave Winer) die Spezifikation von SOAP 1.1 beim World Wide Web Consortium (W3C) einreichten. Dabei hat man das Ziel verfolgt, eine Arbeitsgruppe zu gründen, die SOAP weiterentwickeln sollte. Das Ergebnis dieser Arbeitsgruppe ist SOAP Version 1.2, empfing im Juni 2003 die Anerkennung als recommendation (Empfehlung).

Wie zu Beginn des Beitrags erwähnt, hat man SOAP nicht mehr als gebräuchliche(s) Akronym bzw. Abkürzung verstanden. Der Hauptgrund dafür ist die Tatsache, dass sämtliche Deutungen für SOAP, wie Simple Object Access Protocol oder Service Oriented Architecture Protocol, nicht mehr den vollständigen Sinn von SOAP trafen. Dies ermöglichte die Anmeldung von SOAP als Markennamen in den USA.

Wie funktioniert SOAP?

SOAP ist wie zuvor beschrieben, ein Protokoll zum Austausch XML-Information-Set-basierter Nachrichten über ein Rechnernetz und hat den Status einer W3C-Empfehlung. Es stellt Regeln für das Nachrichtendesign auf. Regelt, wie Daten in der Nachricht abzubilden und zu interpretieren sind. Es gibt eine Konvention für entfernte Prozeduraufrufe mittels SOAP-Nachrichten vor. SOAP macht keine Vorschriften zur Semantik applikationsspezifischer Daten, die man gegebenenfalls versendet möchte, sondern stellt ein Framework (Siehe meinen Beitrag) zur Verfügung, welches erlaubt, dass man beliebige applikationsspezifische Informationen übertragen kann.

Man kann SOAP für entfernte Prozeduraufrufe ebenso nutzen wie für einfache Nachrichtensysteme. Zum Senden von Nachrichten kann man beliebige Transportprotokolle verwendet. Dazu gehören beispielsweise FTP, SMTP, https oder auch JMS. Aus Gründen der Kompatibilität nutzt man in der Praxis hierzu gängige Netzwerk-Architekturen. Auch ist mittels https die verschlüsselte Übertragung von SOAP-Nachrichten möglich. Das ermöglicht jedoch keine End-to-End-Verschlüsselung. Dies kann man durch WS-Security erreichen. Die Einbindung erfolgt lediglich auf der Ebene der Nachrichten und nicht auf der des unterliegenden Transportprotokolls. Folglich ist es so, dass man das XML Information Set der SOAP-Anfrage bei Nutzung von https(S) im Body eines https POST Requests als XML an eine gegebene URL schickt.

In der Regel setzt man SOAP da ein, wo der direkte Zugang fremder Systeme zu einer Informationsquelle nicht sinnvoll erscheint. Dies kann sowohl an Kompatibilitätsproblemen zwischen verschiedenen Anwendungsarchitekturen liegen aber auch an diversen Sicherheitsaspekten. So kann man einen (partiellen) Zugriff auf eine Datenbank ermöglichen, ohne dem Anwenderprogramm den direkten Zugang zu ermöglichen. Die Menge der ausführbaren Methoden reglementiert und definiert man über die SOAP-Schnittstelle.

Die Kommunikation mit SOAP ermöglicht die Kopplung von Systemen. Der offene Entwurf ermöglicht jedoch lediglich den Aufbau schwach gekoppelter Systeme. Die Flexibilität des Konzeptes erkauft man sich durch die Nachteile beim Übertragungsvolumen und Rechenaufwand. Dies kann teuer werden, da man das XML-Dokument beim Sender zunächst aufbaut und anschließend validiert. Das Konzept verfolgt eigentlich das Ziel eines leichtgewichtigen Protokolls.

Doch durch den flexiblen Einsatzbereich führt die zu übertragende Datei eine Reihe von Metadaten mit sich, die bei der Konstruktion des XML-Dokuments weiter anwächst. So führt beispielsweise das einfache Versenden von „Wahr“ oder „Falsch“ zu einem Datenvolumen von mehreren hundert Bytes. In einem stark gekoppelten System sollte dafür theoretisch ein Bit reichen.

Durch die Möglichkeit des flexiblen Aufbaus des Dokuments kann man jedoch auch komplexe Transaktionen in einer Anfrage atomar zusammenfassen, während man in stark gekoppelten Systemen hierzu oftmals mehrere Anfragen erstellen muss. Dies verbessert das Nutzlastverhältnis (Nutzdaten zu Meta-Daten) und den Kommunikationsaufwand (für den Aufbau einer Verbindung, nur ein Senden/Empfangen).

SOAP unterscheidet zwischen dem endgültigen Empfänger und den Zwischenempfängern. Dies ermöglicht es, eine Nachricht über verschiedene „Hops“ zu schicken, bei denen man sogar verschiedene Transportprotokolle verwendet. Beispielsweise kann man zum ersten Hop die Nachricht mittels Java Message Service schicken, im Anschluss über E-Mail und schließlich dem Empfänger mittels https weitergeben. Der Absender muss über die Zwischenhops keine Information haben, die Middleware jedoch schon.

Wie ist eine SOAP-Nachricht aufgebaut?

Eine minimale SOAP-Nachricht besteht aus einem Envelope genannten Element, dem man einen lokalen Namen zuweisen muss. Dieses Element referenziert mittels eines Namensraum-Attributes auf https://www.w3.org/2003/05/soap-envelope. Child dieses Elements muss ein Body-Element sein. Optional kann zuvor ein Header-Element stehen. In diesem kann man Meta-Informationen, beispielsweise zum Routing, zur Verschlüsselung oder zu Transaktionsidentifizierung, unterbringen. Im Body-Element sind die eigentlichen Nutzdaten untergebracht. Dies sieht dann folgendermaßen aus:

<?xml version="1.0"?>
<s:Envelope xmlns:s="https://www.w3.org/2003/05/soap-envelope">
    <s:Header>
    </s:Header>
    <s:Body>
    </s:Body>
</s:Envelope>

Innerhalb des Body-Elements können sowohl Informationen zum Datenaustausch als auch Anweisungen für einen entfernten Prozeduraufruf stehen. Dies ist vom Empfänger entsprechend zu interpretieren.

Im Header gibt man den nächsten Hop (intermediary) und den endgültigen Empfänger (ultimate recipient) an. Ein intermediary kann beispielsweise die Nachricht verschlüsseln, sie loggen oder die Nachricht aufteilen. Ersteres erlaubt es, dass die Anwendungslogik sich nicht um die Sicherheit der Nachricht kümmern muss. Darum kümmert sich die Middleware. Was eine Middleware ist, erkläre ich in einem anderen Beitrag. Die Möglichkeit, dass Intermediaries beliebige Dinge tun können, ermöglicht EAI (Enterprise Application Integration).

Fazit

Viele Altsysteme verwenden möglicherweise noch SOAP. In der Vergangenheit war es auch die Lösung schlechthin. Heute ist es eher REST, welches zum Einsatz kommt und in webbasierten Szenarien häufig als die schnellere Alternative gilt.

Zusammengefasst kann man sagen, dass REST aus einer Reihe von Richtlinien für eine flexible Implementierung besteht und SOAP ein Protokoll mit spezifischen Anforderungen wie XML-Messaging ist.

REST-APIs sind schlank und daher ideal für moderne Anwendungen geeignet, wie das Internet of Things (IoT), mobile Anwendungen und Serverless Computing. SOAP-Webservices bieten zwar integrierte Sicherheit und Transaktions-Compliance, die vielen Unternehmensanforderungen entspricht, doch die Erstellung und Wartung ist wesentlich aufwändiger. Darüber hinaus folgen auch viele öffentlich zugängliche APIsheutzutage, den REST-Richtlinien.

Der Beitrag SOAP – Effiziente Möglichkeit, um Daten zwischen Systemen zu übertragen erschien zuerst auf CEOsBay.

Der Zweck von REST liegt schwerpunktmäßig auf der Maschine-zu-Maschine-Kommunikation. REST stellt eine einfache Alternative zu ähnlichen Verfahren wie SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) und dem verwandten Verfahren RPC (Remote Procedure Call) dar. Anders als bei vielen verwandten Architekturen kodiert REST keine Methodeninformation in den URI (Uniform Resource Identifier), da der URI Ort und Namen der Ressource angibt, nicht aber die Funktionalität, die der Web-Dienst zu der Ressource anbietet. Der Vorteil von REST liegt darin, dass im WWW bereits ein Großteil der für REST nötigen Infrastruktur (z. B. Web- und Application-Server, https-fähige Clients, HTML- und XML-Parser, Sicherheitsmechanismen) vorhanden ist und viele Web-Dienste per se REST-konform sind. Eine Ressource kann dabei über verschiedene Medientypen dargestellt werden, auch Repräsentation der Ressource genannt.

So ist ein Online-Dienst, der lediglich unveränderte Seiteninhalte nach dem Internetstandard https anbietet, bereits REST-konform. Dynamisch erzeugte Seiten folgen diesem Paradigma jedoch meistens nicht. So bieten beispielsweise Nachrichtenseiten sich ständig ändernde Informationen mit sowohl unterschiedlichem Format als auch Inhalt an, die nur schwer automatisch verarbeitet werden können. Bliebe das Format unverändert, so wäre eine essenzielle REST-Eigenschaft erfüllt. So ist eine Webseite, auf der ständig die aktuelle Uhrzeit in immer demselben Format abrufbar ist, REST-konform.

Die Bezeichnung „Representational State Transfer“ soll den Übergang vom aktuellen Zustand zum nächsten Zustand (State) einer Applikation verbildlichen. Dieser Zustandsübergang erfolgt durch den Transfer der Daten, die den nächsten Zustand repräsentieren.

Kurze Zeitreise

Das REST-Paradigma entwickelte sich aus dem 1994 von Roy Fielding entworfenen https Object Model. Fielding entwickelte seine Idee von einem einheitlichen Konzept über die Jahre weiter, bis er 2000 den REST-Architekturstil im Rahmen seiner Dissertation (Hier der Link zu der Arbeit) veröffentlichte. Das Programmierparadigma der „RESTful Application“ wurde allerdings häufig falsch umgesetzt und findet erst seit 2014 Anklang in der Welt des WWW. In seiner Arbeit geht Fielding dabei auf die verschiedenen Anforderungen ein, die für die Webarchitektur wichtig sind.

Wie funktioniert REST?

Der Architektur-Stil verweist auf sechs Eigenschaften, die ein Dienst haben muss. Dabei ist nicht festgelegt, wie man diese Prinzipien implementieren muss. Fielding beschreibt für jedes Architekturprinzip dessen Vor- und Nachteile. Dabei handelt es sich um Client-Server, Zustandslosigkeit, Caching, Einheitliche Schnittstellen, Mehrschichtige Systeme und optional Code on Demand, auf die ich nachfolgend eingehen werde.

• Client-Server (Es gilt generell die Anforderung, dass alle Eigenschaften der Client-Server-Architektur gelten. Der Server stellt dabei einen Dienst bereit, der bei Bedarf vom Client abgefragt wird. Der Hauptvorteil dieser Anforderung ist die einfache Skalierbarkeit der Server, da diese unabhängig vom Client agieren. Dies ermöglicht des Weiteren eine unterschiedlich schnelle Entwicklung der beiden Komponenten.)
  
• Zustandslosigkeit (Jede REST-Nachricht enthält alle Informationen, die für den Server bzw. für den Client notwendig sind, um die Nachricht zu interpretieren. Weder der Server noch die Anwendung soll Zustandsinformationen zwischen zwei Nachrichten speichern. Man spricht daher von einem zustandslosen (englisch: stateless) Protokoll. Jede Anfrage eines Clients an den Server ist insofern in sich geschlossen, als dass sie sämtliche Informationen über den Anwendungszustand beinhaltet, die vom Server für die Verarbeitung der Anfrage benötigt. Zustandslosigkeit in der hier beschriebenen Form begünstigt die Skalierbarkeit eines Webservices. Beispielsweise können eingehende Anfragen im Zuge der Lastverteilung unkompliziert auf beliebige Maschinen verteilt werden, da jede Anfrage in sich geschlossen ist und Anwendungsinformationen somit ausschließlich auf der Seite des Clients vorgehalten werden. Aus diesem Grund ist auf der Seite des Servers keine Sitzungsverwaltung erforderlich. In der Praxis nutzen deswegen viele https-basierte Anwendungen Cookies und andere Techniken, um Zustandsinformationen auf der Client-Seite zu behalten. Weiterhin begünstigt wird die Ausfallsicherheit, weil die Zustandslosigkeit fordert, dass transaktionale Datenübertragung in einem einzigen Seitenaufruf erfolgt. Die Zustandslosigkeit bringt dabei aber den Nachteil mit, dass sich die Netzwerkperformance verschlechtert. Da bei jeder Abfrage alle Informationen zum Interpretieren mitgeschickt werden müssen, sind aufwendigere Abfragen nötig, als wenn sich der Server die Interaktionen merken würde.)
  
• Caching (https-Caching soll genutzt werden, wobei aber gilt: Eine Anfrage, die nicht gestellt werden muss, ist die schnellste Anfrage. Fielding führt dabei den Nachteil auf, dass der Client auf veraltete Cache-Daten zurückgreifen könnte, statt die neue Ressource abzufragen. Wir kennen dies beispielsweise, wenn wir an einer Website unsere Änderungen vorgenommen haben aber die aktualisierten Informationen nach der Synchronisierung mit dem Server nicht richtig angezeigt werden bzw. lediglich die alten Informationen)
  
• Einheitliche Schnittstelle (Dies ist das Hauptunterscheidungsmerkmal aller weiteren Architekturstile. Dabei besteht diese aus vier weiteren Eigenschaften.)

1. Die Adressierbarkeit von Ressourcen, bei der jede Information, die über einen URI kenntlich gemacht wird, als Ressource gekennzeichnet wird. Jeder REST-konforme Dienst eine eindeutige Adresse hat und dem Uniform Resource Locator (URL). Diese „Straße und Hausnummer im Netz“ standardisiert den Zugriffsweg zum Angebot eines Webservices für eine Vielzahl von Anwendungen (Clients). Eine konsistente Adressierbarkeit erleichtert es außerdem, einen Webservice als Teil eines Mashups weiterzuverwenden.
   
2. Repräsentationen zur Veränderung von Ressourcen, wodurch die unter einer Adresse zugänglichen Dienste unterschiedliche Darstellungsformen (Repräsentationen) haben können. Ein REST-konformer Server kann je nachdem, was die Anwendung anfordert, verschiedene Repräsentationen einer Ressource ausliefern, z. B. in verschiedenen Sprachen oder Formaten (HTML, JSON oder XML) oder auch die Beschreibung oder Dokumentation des Dienstes. Die Veränderung einer Ressource (also deren aktuellen Status) soll nur über eine Repräsentation erfolgen.
   
3. Selbstbeschreibende Nachrichten, REST-Nachrichten sollen selbstbeschreibend sein. Dazu zählt u. a. die Verwendung von Standardmethoden. Über diese Standardmethoden lassen sich Ressourcen manipulieren.
   
4. „Hypermedia as the Engine of Application State“ (HATEOAS) laut Fielding die wichtigste Eigenschaft

Ziel ist die Einheitlichkeit der Schnittstelle und somit ihre einfache Nutzung. 

• Mehrschichtige Systeme, bei dem die Systeme mehrschichtig aufgebaut sein sollen. Dadurch reicht es, dem Anwender lediglich eine Schnittstelle anzubieten. Dahinterliegende Ebenen können verborgen bleiben und somit die Architektur insgesamt vereinfachen. Vorteile dabei sind die bessere Skalierbarkeit der Server, sowie eine mögliche Abkapselung durch Firewalls. Durch Cache-Speicher an den Grenzen (z.B. vom Server zum Web) steigert man die Effizienz der Anfragen (Siehe Caching).
  
• Code on Demand, wobei diese Forderung von Fielding optional ist. Unter Code on Demand versteht man die Übertragung an den Client Code erst im Bedarfsfall. Folglich zur lokalen Ausführung. Ein Beispiel hierfür wäre die Übertragung von JavaScript-Code bei einer HTML-Repräsentation.

Folglich kommt für die Umsetzung des REST-Paradigmas ein zustandsloses Client-Server-Protokoll zum Einsatz. Als Anwendungsschicht-Protokolle werden hauptsächlich https und https eingesetzt. Dies liegt unter anderem daran, dass sich diese im WWW etabliert haben, über einen vergleichsweisen einfachen Aufbau verfügen und mit so gut wie jeder Firewall kompatibel sind. REST vereinheitlicht die Schnittstelle zwischen Systemen auf eine überschaubare und bezüglich des zu erwartenden Verhaltens standardisierte Menge von Aktionen. Welche Aktionen dies sind, ist in REST nicht festgelegt aber alle Aktionen sind allgemein definiert. In der Regel durch die verwendeten Protokolle der Anwendungsschicht.

Während REST als Abstraktion des WWW keine spezielle Implementierung und kein spezielles Protokoll fordert, ist doch zu beobachten, dass fast ausschließlich https zum Einsatz kommt. Dadurch werden auch die Menge der Aktionen festgelegt.

Wird über https zugegriffen, so gibt die verwendete https-Methode, darunter GET, POST, PUT und DELETE, an, welche Operation des Dienstes gewünscht ist. https schreibt vor, dass GET „safe“ (sicher) sein muss, was bedeutet, dass diese Methode nur Informationen beschafft und keine sonstigen Effekte verursacht. Die Methoden GET, HEAD, PUT und DELETE müssen laut https-Spezifikation idempotent (dasselbe) sein, was in diesem Zusammenhang bedeutet, dass das mehrfache Absenden der gleichen Anforderung sich nicht anders auswirkt als ein einzelner Aufruf. Abhängig von der Implementierung können noch weitere https-Befehle unterstützt werden. Dazu gehören COPY, MOVE, MKCOL, LOCK und UNLOCK des WebDAV-Protokolls, sowie LINK und UNLINK aus RFC 2068. Bei der Kommunikation über UDP kann zudem das CoAP aus RFC 7252 statt https eingesetzt werden, welches leicht abweichende Bedeutungen für GET, POST, PUT und DELETE besitzt.

Fazit

Die meisten Unternehmen verwenden den REST-Architekturstil für die Entwicklung / Implementierung von Webdiensten, da es sich um eine einfache und benutzerfreundliche Oberfläche handelt, die weniger Schulung für die vorhandenen / neuen Mitglieder des Projekts erfordert. Unternehmen erwägen REST zusammen mit ihren vorhandenen Webdiensten.

Der Beitrag REST – Schönheit der einfachen Architektur erschien zuerst auf CEOsBay.

Ab wann werden Frameworks relevant?

In der Regel definiert man als Programmierer oder als Team, zu Beginn eines Projekts, auf Basis der Anforderungen und der wirtschaftlichen Aspekte, die Herangehensweise.

Man hat immer die Auswahl, alles von Grund auf selber bzw. nativ zu programmieren, was zwar eine extrem individuelle Lösung darstellt und alles bis auf das kleinste Detail erstellt bzw. programmiert werden kann, ein CMS (Content Management System = Eine Software zur gemeinschaftlichen Erstellung, Bearbeitung, Organisation und Darstellung digitaler Inhalte zumeist zur Verwendung in Webseiten aber auch in anderen Medienformen) zu nutzen – Wobei ich Zweites in einem separaten Beitrag ausführlich thematisieren möchte (Übrigens basiert diese Webseite auch auf einem CMS. In diesem Fall handelt es sich um eine WordPress-Instanz). Und dann gibt es natürlich Frameworks. Wobei die Anforderungen an die Professionalität des Entwicklers bei dieser Herangehensweise relativ hoch angesiedelt sind. Allerdings muss man sagen, dass das hohe Maß an Flexibilität und die Verfügbarkeit ausgefeilter Struktur-Merkmale nicht unwesentlich sind.

Welche Frameworks gibt es?

Application Frameworks: Als Grundgerüst für die Programmierung von Anwendungen mit spezifischen Strukturen und Funktionen.

Web-Frameworks: Für die Entwicklung und Programmierung dynamischer Web-Sites und Web-Anwendungen.

Komponenten-Frameworks: Als Umgebungsrahmen für die Programmierung und Einbindung von Programm-Paketen.

Domain Frameworks: Als Rahmen für vordefinierte Problembereiche.

Coordination Frameworks: Zur Einrichtung von Geräte-Interaktionen bzw. für die Abfolge zu steuernder Einzelschritte.

Class Frameworks: Zur Zusammenfassung von „Klassen“ und „Methoden“, im Sinne einer optimalen Unterstützung des Programmierers bei der Implementierung seiner spezifischen Anwendungen.

Test Frameworks: Für das Testen von Programmen. Klassische Beispiele hierfür sind „Selenium“ für den Test von Webanwendungen und „JUnit“ für den Test von Modulen. Selenium habe ich in diesem Beitrag thematisiert.

Fazit

Eines der Vorteile ist, wie bereits erwähnt, dass Wiederkehrende Aufgaben schneller abgewickelt werden können, da im Framework bereits eine Reihe an Elementen vorprogrammiert sind. Diese können beliebig oft verwendet werden. Darüberhinaus beinhalteten Frameworks Basis-Bausteine, die auf die Design-Struktur eines Programms Einfluss nehmen. Sie bieten sich in der Regel bei speziellen Anforderungen und individuellen Lösungen an, so kann das vom Framework zur Verfügung gestellte Programmier-Gerüst eine gute Wahl darstellen. Nichtsdestotrotz sollte man meines Erachtens nach bei „kleineren“ Projekten die Nutzung von Content Management Systemen in Erwägung ziehen. Schlussendlich, hängt die Wahl der jeweiligen Herangehensweise und die Effizienz, in der das Projekt realisiert wird, häufig von der Qualifikation und dem Skillset eines jeden Programmierers ab.

Der Beitrag Frameworks – Effiziente Entwicklung und eine höhere Qualität durch Rahmenwerke erschien zuerst auf CEOsBay.