Anmelden / Registrieren Konto

Integration

APIs – Einsatz und Funktionsweise

Eine API besteht aus mehreren Tools, Definitionen und Protokollen zur Entwicklung und Integration von Anwendungssoftware. API steht für Application Programming Interface.

Mit ihr können Produkte oder Services unabhängig von ihrer Implementierung untereinander kommunizieren. Auf diese Weise lässt sich die Anwendungsentwicklung optimieren, was wiederum Zeit und Geld spart. Sie sind flexibel und vereinfachen die Handhabung, egal ob Sie neue Tools und Produkte entwickeln oder bestehende verwalten. Obendrein schaffen sie Möglichkeiten für Innovationen.

APIs werden zuweilen als Verträge mit Dokumenten angesehen, die eine Vereinbarung zwischen Partien repräsentieren: Wenn eine Partei eine in einer bestimmten Weise strukturierte Remote-Anfrage sendet, antwortet die zweite Partei entsprechend.

Da APIs die Integration neuer Anwendungskomponenten in eine bestehende Architektur für die Entwickler vereinfachen, unterstützen sie automatisch die Zusammenarbeit zwischen Unternehmen und IT-Teams. Als Unternehmen muss man oft flexibel auf die sich ständig verändernden Bedingungen des Marktes reagieren können, in dem ein Mitbewerber beispielsweise die gesamte Branche mit einer einzigen neuen App transformieren kann. Um wettbewerbsfähig zu bleiben, ist eine schnelle Entwicklung und Bereitstellung innovativer Services deshalb unerlässlich. Eine Methode zur Beschleunigung des Prozesses ist die cloudnative Anwendungsentwicklung, die auf der Verknüpfung einer Architektur aus Microservice-Anwendungen über APIs basiert.

APIs selbst bieten eine einfache Möglichkeit zur Anbindung Ihrer eigenen Infrastruktur über die Entwicklung cloudnativer Anwendungen, ermöglichen aber auch die gemeinsame Verwendung Ihrer Daten mit Kunden und anderen externen Nutzern. Öffentliche APIs repräsentieren einen hohen Geschäftswert, weil sie die Verbindung zu Ihren Partnern vereinfachen und gleichzeitig erweitern und dazu für eine mögliche Monetarisierung Ihrer Daten sorgen (ein gängiges Beispiel ist hier die Google Maps API).

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 Grundlage der API-Sicherheit ist ein gutes API-Management. Die Verbindung mit APIs und die Entwicklung von Anwendungen, die von den APIs bereitgestellte Daten oder Funktionen verwenden, lässt sich mit einer verteilten Integrationsplattform durchführen, die alles miteinander verbindet, auch Altsysteme 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.

Die Vorteile der 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 Computing, 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 Oberfläche: Diese Vorgabe ist wesentlich für das Design von RESTful APIs und umfasst 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.

Dies hört sich nach vielen Vorgaben an, aber im Grunde sind diese Vorgaben viel einfacher zu befolgen als ein vorgeschriebenes Protokoll. Dies ist der Grund, warum sich RESTful APIs gegenüber SOAP immer stärker durchsetzen.

In der jüngeren Vergangenheit hat sich die OpenAPI-Spezifikation  als gemeinsamer Standard für die Definition von REST APIs etabliert. Sie bietet einen sprachunabhängigen Ansatz, mit dem Entwickler REST API-Schnittstellen bauen können, die Nutzer ohne große Probleme verstehen.

SOA oder 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. Durch diese schlanke Architektur werden Cloud- oder verteilte Ressourcen optimiert und eine dynamische Skalierbarkeit einzelner Services unterstützt.

APIs und Red Hat

Mit Red Hat erhalten Sie modulare, kompakte und umfassende Open Source API-Lösungen mit offenen Standards, die lokal oder in der Cloud verfügbar sind. Sie sind mit entscheidend dafür, dass Sie Ihre aktuelle Integrationsinfrastruktur flexibler machen und Werte schneller realisieren können.

Plattform

Integrieren Sie unterschiedliche IT-Assets mit einer verteilten, flexiblen Integrationsplattform. Mit Red Hat Fuse erhalten Sie die Infrastruktur und notwendigen Tools, mit denen Sie einfach alles integrieren können.

Plattform

Verwalten Sie Ihre APIs für interne und externe Nutzer auf einer Plattform, auf der APIs ohne Probleme verteilt, gesichert, gesteuert, gemeinsam genutzt und monetarisiert werden können.

APIs haben noch viel mehr zu bieten