Was ist eine API?

APIs (Application Programming Interfaces oder Programmierschnittstellen) bestehen aus mehreren Definitionen und Protokollen zur Entwicklung und Integration von Anwendungssoftware. Eine API ist eine Schnittstelle, die es unabhängigen Anwendungen ermöglicht, miteinander zu kommunizieren und Daten auszutauschen.

Mithilfe von APIs können Ihre 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 Design, Administration und Nutzung von Anwendungen – 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 Entwicklerinnen und 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 Usern. Öffentliche APIs stellen einen hohen Geschäftswert dar, denn sie vereinfachen und erweitern die Verbindung zu Ihren Partnern und sorgen zudem für eine mögliche Monetarisierung Ihrer Daten (ein gängiges Beispiel ist hier die Google Maps API).

Anwendungsbeispiel:

Nehmen wir als Beispiel einen Buchversand. Ein solches Unternehmen könnte seinen Kundinnen und Kunden eine cloudbasierte App zur Verfügung stellen und den Beschäftigten der Buchhandlungen so die Möglichkeit geben, die Verfügbarkeit bestimmter Bücher beim Versand anzufragen. 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 Entwicklungsteams, die für den Buchversand, den Buchhandel oder Dritte tätig sind, Apps erstellen, um 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 Zugang zu Ihren Ressourcen gewähren, ohne bei Sicherheit und Kontrolle Einbußen zu machen. Wie und für wen Sie diesen Zugriff gewähren, bleibt ganz Ihnen überlassen. Bei der API-Sicherheit dreht sich alles um ein gutes API-Management, das die Verwendung eines API-Gateways umfasst. Die Verbindung mit APIs und die Entwicklung von Anwendungen, die von den APIs bereitgestellte Daten oder Funktionen nutzen, lässt sich mit einer verteilten Integrationsplattform durchführen, die alles miteinander vernetzt, auch Altsysteme und das IoT (Internet of Things).

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äuferinnen und 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 Kundinnen und 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 Entwicklungsteams 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 internes Entwicklungsteam. 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.

APIs finden in vielen Unternehmensbereichen ihren Einsatz. Finden Sie heraus, wie beispielsweise eine offene API-Technologiestrategie für Versicherungsunternehmen funktionieren kann:

APIs stammen aus den frühen Tagen des Computings, und zwar weit vor dem PC. Damals wurden sie primär als Library 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 sind auf die Interaktion über ein Kommunikationsnetzwerk ausgelegt. Dabei bezieht sich „remote“ darauf, 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.

Mit den sich ständig verbreitenden Web-APIs wurde eine Protokollspezifikation entwickelt, um den Informationsaustausch zu standardisieren: das SOAP (kurz für Simple Object Access Protocol). 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 REST (Representational State Transfer). 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 Architekturstil. 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.
• Zustandslosigkeit: 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.
  • Selbstbeschreibende Nachrichten: Jede an einen Client zurückgegebene Nachricht enthält genügend Informationen, die die Art und Weise der Verarbeitung durch den Client 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. Aus diesem Grund setzen sich RESTful APIs gegenüber SOAP immer stärker durch.

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 Entwicklungsteams REST-API-Schnittstellen erstellen können, die von den Nutzenden ohne große Probleme verstanden werden.

Ein weiterer aufstrebender API-Standard ist GraphQL, eine Abfragesprache und serverseitige Runtime, die als Alternative zu REST verwendet werden kann. Dank der Priorisierung stellt GraphQL den Clients nur diejenigen Daten zur Verfügung, die sie wirklich brauchen. Mit dieser Alternative zu REST können Entwicklungsteams Anfragen strukturieren, die mit einem einzigen API-Aufruf Daten aus mehreren Quellen gleichzeitig abrufen.

Die zwei Ansätze, die Remote-APIs am meisten verwenden, sind die SOA (Service-Oriented Architecture) und die Microservice-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.

Ein Webhook ist eine HTTP-basierte Rückmeldungsfunktion, die eine schlanke, event-gesteuerte Kommunikation zwischen zwei APIs ermöglicht. Webhooks werden von einer Vielzahl von Webanwendungen verwendet, um kleine Datenmengen von anderen Anwendungen zu empfangen. Sie können aber auch verwendet werden, um Automatisierungs-Workflows in GitOps-Umgebungen auszulösen.

Webhooks werden oft als Reverse-APIs oder Push-APIs bezeichnet, weil sie die Verantwortung für die Kommunikation auf den Server und nicht auf den Client übertragen. Anstelle des Clients, der HTTP-Anfragen sendet – also Daten anfordert, bis der Server antwortet – sendet der Server dem Client eine einzige HTTP-POST-Anfrage, sobald die Daten verfügbar sind. Ungeachtet des Namens sind Webhooks keine APIs; sie arbeiten zusammen. Eine Anwendung muss über eine API verfügen, um einen Webhook zu verwenden.