Was ist eine API?

APIs oder Application Programming Interfaces bestehen aus mehreren Definitionen und Protokollen zur Entwicklung und Integration von Anwendungssoftware.

APIs ermöglichen die Kommunikation Ihres Produkts oder Services mit anderen Produkten und Services, ohne dass Sie wissen müssen, wie diese implementiert wurden. Auf diese Weise lässt sich die Anwendungsentwicklung optimieren, was wiederum Zeit und Geld spart. So erhalten Sie bei der Entwicklung neuer Tools und Produkte – oder der Verwaltung bereits bestehender – mehr Flexibilität. Zusätzlich werden Design, Administration und Nutzung vereinfacht und Möglichkeiten zur Innovation geschaffen.

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

Da APIs die Integration neuer Anwendungskomponenten in eine bestehende Architektur 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 Mitbewerber beispielsweise mit einer neuen App die gesamte Branche transformieren können. Um wettbewerbsfähig zu bleiben, ist die schnelle Entwicklung und Bereitstellung innovativer Services unerlässlich. Die cloudnative Anwendungsentwicklung bietet eine bewährte Möglichkeit, die Entwicklungsgeschwindigkeit zu beschleunigen, und basiert auf der Verbindung einer Microservices-Anwendungsarchitektur über APIs.

APIs selbst bieten eine einfache Möglichkeit zur Anbindung Ihrer eigenen Infrastruktur über die cloudnative Anwendungsentwicklung, ermöglichen aber auch die gemeinsame Nutzung Ihrer Daten mit Kunden und anderen externen Nutzenden. Ö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 Buchvertrieb. Ein solches Unternehmen könnte seinen Kunden eine Cloud-App zur Verfügung stellen, mithilfe derer Mitarbeitende 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 Buchvertrieb 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 Buchvertrieb 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 Buchvertrieb, 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äftschancen 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, das auch die Verwendung eines API-Gateways umfasst. 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).

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 Zusammenarbeit erleichtern oder verbessern

Das klingt gut, nicht wahr? Wie aber ist all das mit APIs möglich?

Lassen Sie uns zum Beispiel mit dem Buchvertrieb 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. Dieses verbesserte Erlebnis lockt mehr Kundschaft in die Buchhandlung – den Kunden des Buchvertriebs – und erweitert damit eine bestehende Einnahmequelle.

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

Das Teilen von APIs weltweit oder mit ausgewählten Partnern kann positive Auswirkungen haben. Mit neuen Partnerschaften erweitert sich der Bekanntheitsgrad Ihrer Marke über Ihre Marketing-Bemühungen hinaus. Durch das Bereitstellen von Technologie an die Öffentlichkeit, wie bei einer öffentlichen API, werden Entwicklungsteams dazu angeregt, ein App-Ökosystem auf Basis Ihrer API zu schaffen. Je mehr Menschen Ihre Technologie nutzen, desto wahrscheinlicher ist es, dass sie mit Ihnen geschäftlich zusammenarbeiten.

Die Veröffentlichung von Technologie kann neuartige und unerwartete Auswirkungen haben. Diese führen ab und an zu einer Disruption ganzer Branchen. Für den Buchvertrieb könnten neue Firmen, wie beispielsweise ein Buchleihgeschäft, ihre Geschäftstätigkeit komplett verändern. Partner- und öffentliche APIs ermöglichen die Nutzung der kreativen Bemühungen einer Community, die um vieles größer ist als Ihr internes Entwicklungsteam. Neue Ideen entstehen auf vielfältige Weise, weshalb sich Unternehmen jederzeit über Marktänderungen bewusst sein und entsprechend reagieren können müssen. Hier können APIs helfen.

APIs stammen aus den frühen Tagen des Computing, lange bevor es den PC gab. 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. Mit „remote“ ist gemeint, 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 haben in der Regel die Form einer XML- oder JSON-Datei. 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: 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. Das bedeutet, 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 6 Hauptvorgaben des RESTful-Systems erfüllen:

• Client/Server-Architektur: Eine REST-Architektur besteht aus Clients, Servern und Ressourcen. Anfragen werden per HTTP gehandhabt.
• Zustandslosigkeit: Auf dem Server werden zwischen Anforderungen 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 gegebenenfalls zusätzliche Funktionen wie Load Balancing, gemeinsame Caches oder Sicherheit ausführen.
• Code on Demand (optional): Server können die Funktionalität eines Clients durch die Übertragung von ausführbarem Code erweitern.
• Einheitliche Oberfläche: Diese Vorgabe ist wesentlich für das Design von RESTful APIs und umfasst 4 Aspekte:
  • Ressourcenidentifikation in Anforderungen: Ressourcen werden in Anforderungen identifiziert und sind von den an den Client zurückgegebenen Darstellungen getrennt.
  • Ressourcenmanipulation durch Darstellungen: 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 ausreichende Informationen, um zu beschreiben, wie der Client die Informationen verarbeiten soll.
  • Hypermedia als Engine des Anwendungsstatus: Nach dem Zugriff auf eine Ressource sollte der REST-Client in der Lage sein, über Hyperlinks die anderen aktuell verfügbaren Aktionen zu identifizieren.

Dies hört sich nach vielen Vorgaben an, aber im Grunde sind diese Vorgaben viel einfacher zu befolgen als ein vorgeschriebenes Protokoll. Darum setzen sich RESTful APIs gegenüber SOAP weiter stärker durch.

Seit einigen Jahren 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 bauen können, die Nutzende ohne große Probleme verstehen.

Ein weiterer neuer API-Standard ist GraphQL, eine Abfragesprache und serverseitige Runtime, die eine Alternative zu REST darstellt. GraphQL priorisiert, dass dem Client genau die Daten zur Verfügung gestellt werden, die er anfordert. Als Alternative zu REST können Entwicklungsteams mit GraphQL Anforderungen erstellen, mit denen Daten aus mehreren Datenquellen in einem einzigen API-Aufruf abgerufen werden.

Mehr über die Unterschiede zwischen SOAP und REST erfahren

Die 2 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 entwickelte sich ursprünglich als eine Verbesserung gegenüber monolithischen Anwendungen. 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 Architekturen 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 neuer Funktionen und Updates. Sämtliche dieser Services sind diskret. Daher lassen sie sich ohne Beeinträchtigung der anderen Services in der Architektur ersetzen, verbessern oder löschen. Dank dieser schlanken Architektur lassen sich verteilte Ressourcen oder Cloud-Ressourcen optimieren und einzelne Services dynamisch skalieren.

Mehr über SOA erfahren

Ein Webhook ist eine HTTP-basierte Callback-Funktion, die eine schlanke, eventgesteuerte Kommunikation zwischen 2 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. 

Mehr über Webhooks erfahren

MCP (Model Context Protocol) und APIs fungieren als digitale Bridges, die eine Verbindung zwischen separaten Systemen ermöglichen. MCP-Funktionen bauen auf APIs auf, und ohne APIs würde es MCP nicht geben. 

Die Technologien unterscheiden sich in ihrer Funktionsweise und ihrem Zweck:

• MCP verbindet Sprachmodelle mit externen Tools und Daten und ermöglicht so Workflows, die sich in Echtzeit anpassen und improvisieren lassen. 
• Traditionelle API-Workflows folgen einem festen Satz von Regeln. Sobald 2 Systeme verbunden sind, können sie nur über die vom Entwicklungsteam programmierten Aktionen miteinander interagieren.

Mehr über MCP im Vergleich zu APIs erfahrenSeite verfügbar in Englisch (Deutsch ist nicht verfügbar)