Integration

Was sind APIs?

Eine API (Application Programming Interface) ist ein Satz mit Tools, Definitionen und Protokollen zur Entwicklung von Anwendungssoftware. Mit ihr können Produkte oder Services unabhängig von ihrer Implementierung untereinander kommunizieren. Mit APIs lässt sich die Anwendungsentwicklung vereinfachen und damit der Zeit- und Kostenaufwand für Entwickler und Unternehmen verringern. Sie bieten Flexibilität sowie eine einfache Konzipierung, Verwaltung und Nutzung, egal ob Sie neue Tools und Produkte entwickeln oder bestehende verwalten. Obendrein schaffen sie Möglichkeiten für die Innovation.

Nehmen wir als Beispiel einen Buchversand. Ein solches Unternehmen könnte seinen Kunden eine App zur Verfügung stellen, mithilfe derer Mitarbeiter die Verfügbarkeit bestimmter Bücher beim Versand anfragen können. Diese App könnte potenziell teuer in der Entwicklung oder auf bestimmte Plattformen beschränkt sein sowie lange Entwicklungszeiten und eine kontinuierliche Wartung erfordern.

Als Alternative könnte der Buchversand eine API zur Prüfung der Verfügbarkeit bereitstellen. Dieser Ansatz bietet verschiedene Vorteile:

  • Indem man dem Kunden Datenzugriff über eine API gewährt, ermöglicht man ihm direkten Zugang zu Bestandsinformationen.
  • Der Buchversand kann Änderungen an seinen internen Systemen vornehmen (solange dadurch das API-Verhalten nicht geändert wird), ohne dass dies seine Kunden beeinträchtigt.
  • Mit einer öffentlich verfügbaren API können Entwickler, die für den Buchversand, Buchverkäufer oder Dritte tätig sind, Apps erstellen, um dem Kunden die Suche nach Büchern zu erleichtern. Dies wiederum kann zu höheren Umsätzen und anderen Geschäftsmöglichkeiten führen.

Kurz gesagt, mit APIs können Sie bei gleichzeitiger Aufrechterhaltung der Sicherheit und Kontrolle Zugang zu Ihren Ressourcen gewähren. Wie und für wen Sie diesen Zugriff gewähren, bleibt ganz Ihnen überlassen. Die Verbindung mit APIs bzw. Entwicklung von Anwendungen, die von APIs bereitgestellte Daten oder Funktionen konsumieren, lässt sich mit einer verteilten Integrationsplattform durchführen, die einfach alles miteinander verknüpft, darunter auch Legacy-Systeme und das Internet of Things (IoT).

Es gibt drei Ansätze für API-Release-Richtlinien.

Privat

Solche APIs sind ausschließlich für den internen Gebrauch gedacht. Dieser Ansatz bietet Unternehmen die größtmögliche Kontrolle über Ihre APIs.

Partner

Die API wird mit spezifischen Geschäftspartnern geteilt. Damit kann man sich zusätzliche Einnahmequellen erschließen, ohne die Qualität zu beeinträchtigen.

Öffentlich

Diese API steht jedermann zur Verfügung. So können Dritte Apps für die Interaktion mit Ihrer API entwickeln und öffnet Innovationsmöglichkeiten.

Innovation mit APIs

Die Öffnung Ihrer APIs für Partner oder die Öffentlichkeit kann:

  • zur Erschließung neuer oder Erweiterung aktueller Einnahmequellen führen.
  • die Reichweite Ihrer Marke vergrößern.
  • die offene Innovation oder Effizienz durch externe Entwicklung und Kollaboration erleichtern oder verbessern.

Zu schön um wahr zu sein? Wie aber ist all das mit APIs möglich?

Lassen Sie uns zum Beispiel mit dem Buchversand zurückkehren.

Nehmen wir an, eine der Partnerfirmen entwickelt eine App, mit denen sich die genaue Position von Büchern auf dem Regal bestimmen lässt. Diese verbesserte Erfahrung bringt womöglich mehr Käufer in den Laden (des Kunden des Buchversands) und ermöglicht den Ausbau einer bereits bestehenden Einnahmequelle.

Vielleicht entwickelt ein Drittunternehmen auf Basis einer öffentlichen API eine App, mit der Kunden Bücher anstatt im Laden direkt beim Buchversand bestellen können. Dies eröffnet eine neue Einnahmequelle für den Buchversand.

Das Teilen von APIs mit ausgewählten Partnern oder der ganzen Welt kann positive Auswirkungen haben. Mit jeder Partnerschaft erweitert sich der Bekanntheitsgrad Ihrer Marke über Ihre Marketing-Bemühungen hinaus. Durch die Bereitstellung von Technologie an die Öffentlichkeit, wie bei einer öffentlichen API, werden Entwickler zur Schaffung eines App-Ökosystems auf Basis Ihrer API angeregt. Je mehr Menschen Ihre Technologie verwenden, desto mehr werden höchstwahrscheinlich Geschäftsbeziehungen zu Ihnen aufbauen.

Die Veröffentlichung von Technologie kann neuartige und unerwartete Auswirkungen haben. Diese führen ab und an zu einer Disruption ganzer Branchen. Für unseren Buchversand könnten neue Firmen, wie z. B. ein Buchleihgeschäft, ihre Geschäftstätigkeit komplett verändern. Partner- und öffentliche APIs ermöglichen die Nutzung der kreativen Bemühungen einer Gemeinschaft, die um vieles größer ist als Ihr Team an internen Entwicklern. Neue Ideen können auf diese Weise von überall her kommen, weshalb sich Unternehmen jederzeit über Marktänderungen bewusst sein und entsprechend reagieren können müssen. Hier können APIs helfen.

Eine ganz kurze Geschichte der APIs

APIs stammen aus den frühen Tagen des Computings, und zwar weit vor dem PC. Damals wurden sie primär als Bibliothek für Betriebssysteme benutzt. Sie agierten zumeist auf dem jeweiligen System ihrer Installation, waren ab und an aber auch für die Weiterleitung von Nachrichten zwischen Mainframes zuständig. Fast 30 Jahre später hatten die APIs endlich die Grenzen ihrer lokalen Umgebungen überwunden. Anfang des neuen Jahrtausends wurden sie dann zu einer wichtigen Technologie für die Remote-Integration von Daten.

Remote-APIs

Remote-APIs sind auf die Interaktion über ein Kommunikationsnetzwerk ausgelegt. „Remote“ bedeutet hier, dass sich die mit der API manipulierten Ressourcen außerhalb des lokalen anfragenden Computersystems befinden. Da das Internet das am weitesten verbreitete Kommunikationsnetzwerk ist, werden die meisten APIs basierend auf Webstandards entwickelt. Nicht alle Remote-APIs sind Web-APIs, aber man kann davon ausgehen, dass Web-APIs im Grunde „remote“ sind.

Web-APIs verwenden zur Nachrichtenabfrage typischerweise HTTP und stellen eine Definition der Struktur der Antwortmeldungen bereit. Diese Antwortmeldungen nehmen meist die Form eine XML- oder JSON-Datei an. Sowohl XML als auch JSON werden als Format bevorzugt, weil sie Daten auf eine Weise präsentieren, die den Apps die Manipulation erleichtert.


Was wird im Bereich API-Verbesserung unternommen?

Da sich APIs mittlerweile zur allgegenwärtigen Form der Web-APIs gewandelt haben, wurden verschiedene Anstrengungen unternommen, um ihr Design einfacher und ihre Implementierung nützlicher zu machen.

Ein wenig SOAP und viel REST

Mit den sich ständig verbreitenden Web-APIs wurde eine Protokollspezifikation entwickelt, um den Informationsaustausch zu standardisieren: das Simple Object Access Protocol, kurz SOAP. Mit SOAP erstellte APIs nutzen XML als Nachrichtenformat und erhalten Anforderungen per HTTP oder SMTP. SOAP vereinfacht den Informationsaustausch für in unterschiedlichen Umgebungen ausgeführte oder unterschiedlichen Sprachen geschriebene Apps.

Eine weitere Spezifikation ist Representational State Transfer (REST). Web-APIs, die den Rahmenbedingungen der REST-Architektur unterliegen, nennt man RESTful APIs. REST unterscheidet sich grundlegend von SOAP: SOAP ist ein Protokoll, REST ein Architekturdesign. Will heißen, es gibt keinen offiziellen Standard für RESTful Web-APIs. Wie in der Dissertation „Architectural Styles and the Design of Network-based Software Architectures“ von Roy Fielding dargelegt, fallen APIs in die RESTful-Kategorie, wenn sie die sechs Hauptvorgaben des RESTful-Systems erfüllen:

  • Client/Server-Architektur: REST-Architekturen bestehen aus Clients, Servern und Ressourcen. Anfragen werden per HTTP gehandhabt.

  • Statelessness: Auf dem Server werden zwischen Anfragen keine Client-Inhalte gespeichert. Informationen zum Sitzungsstatus werden stattdessen auf dem Client gesichert.

  • Caching-Fähigkeit: Mit Caching lassen sich Anforderungen für manche Client/Server-Interaktionen eliminieren.

  • Mehrschichtsystem: Client/Server-Interaktionen können auf mehrere Schichten erweitert werden. Über sie lassen sich ggf. zusätzliche Funktionen wie Lastverteilung, gemeinsame Caches oder Sicherheit ausführen.

  • Code on Demand (optional): Die Funktionalität eines Clients lässt sich vom Server per Übertragung des ausführbaren Codes erweitern.

  • Einheitliche Schnittstelle: Diese Vorgabe ist wesentlich für das Design von RESTful APIs und integriert vier Aspekte:

    • Ressourcenidentifizierung in der Anfrage: Die Ressourcen werden in der jeweiligen Anfrage identifiziert und sind von den an den Client zurückgegebenen Darstellungen getrennt.

    • Ressourcenmanipulation durch Darstellungen: Die Clients empfangen Dateien, die Ressourcen darstellen. Diese Darstellungen müssen ausreichende Informationen enthalten, um eine Änderung oder Löschung zu ermöglichen.

    • Selbstbeschreibungsfähige Nachrichten: Jede an einen Client zurückgegebene Nachricht enthält ausreichende Informationen, um die Art und Weise der Verarbeitung durch den Client zu beschreiben.

    • Hypermedia als Engine des Anwendungsstatus: Nach dem Zugriff auf eine Ressource sollte der REST-Client in der Lage sein, über Hyperlinks alle anderen aktuell verfügbaren Maßnahmen zu identifizieren.

Hört sich wie eine ganze Menge an Vorgaben an, aber im Grunde gestalten sie sich viel einfacher als ein vorgeschriebenes Protokoll. Aus diesem Grund setzen sich RESTful APIs gegenüber SOAP immer mehr durch.

SOA vs. Microservices-Architektur

Die zwei Ansätze, die Remote-APIs am meisten verwenden, sind die SOA (Service-Oriented Architecture) - und die Microservices-Architektur. Die SOA ist die ältere der beiden und begann als Verbesserung der monolithischen Apps. Während eine einzelne monolithische App volle Funktionalität bietet, können manche Funktionen von unterschiedlichen Apps übernommen werden, die über ein Integrationsmuster wie ein Enterprise Service Bus (ESB) lose gekoppelt sind.

Zwar ist die SOA in vielerlei Hinsicht einfacher als eine monolithische Architektur, bei ihr besteht allerdings die Gefahr, dass Änderungen durch die Umgebung kaskadiert werden, wenn die Komponenteninteraktionen nicht richtig verstanden werden. Diese zusätzliche Komplexität führte zu manchen der Probleme, die mithilfe von SOA gelöst werden sollten.

Microservices-Architekturen sind SOA-Mustern in Bezug auf die Verwendung spezieller, lose gekoppelter Services ähnlich. Aber sie gehen bei der Aufschlüsselung traditioneller Infrastrukturen sogar noch einen Schritt weiter. Die Services innerhalb der Microservices-Architektur nutzen ein gemeinsames Messaging-Framework wie RESTful APIs. So können Sie über diese APIs miteinander kommunizieren, und zwar ohne komplexe Datenumwandlungstransaktionen oder zusätzliche Integrationsschichten. Der Einsatz von RESTful APIs ermöglicht und fördert sogar die schnelle Bereitstellung von neuen Funktionen und Updates. Alle Services sind diskret. So können sie ohne Beeinträchtigung der anderen Services in der Architektur ersetzt, verbessert oder gelöscht werden. Diese kompakte Architektur unterstützt die Optimierung von Cloud- oder verteilten Ressourcen und die dynamische Skalierbarkeit einzelner Services.

APIs and Red Hat

Red Hat gives you modular, lightweight, and comprehensive API solutions that are open source, open standards, and available on-premise or in the cloud.

Platform

Integrate your diverse IT assets with a distributed, flexible integration platform. Red Hat Fuse provides the infrastructure and tooling you need to integrate everything.

Platform

Manage your APIs for internal and external users with a platform that makes APIs easy to share, secure, distribute, control, and monetize.

APIs haben noch viel mehr zu bieten