API (Application Programming Interface)

Was ist eine API?

Eine API ist eine definierte Grenze zwischen Softwarekomponenten. Sie beschreibt, welche Funktionen ein System nach außen anbietet und unter welchen Bedingungen andere Anwendungen diese Funktionen nutzen können. Der aufrufende Client muss dafür nicht wissen, wie die interne Logik implementiert ist.

Das Prinzip ist älter und breiter als Web-APIs. Programmiersprachen, Betriebssysteme, Bibliotheken und Datenbanken besitzen ebenfalls Schnittstellen. Im Unternehmensalltag ist mit „API“ heute jedoch häufig eine HTTP-basierte Web-API gemeint.

Warum sind APIs für Systemintegration wichtig?

Unternehmen nutzen meist nicht nur ein einziges System. CRM, ERP, Website, Shop, Buchhaltung, Kundenportal oder interne Anwendung müssen Informationen austauschen. Eine sauber definierte API reduziert dabei direkte Abhängigkeiten zwischen den internen Implementierungen.

Statt Daten per Datei oder manueller Übertragung weiterzugeben, kann eine Anwendung beispielsweise einen Kunden, Auftrag oder Status über eine Schnittstelle lesen oder aktualisieren.

Fachliche Grundlage: HTTP und OpenAPI

Viele moderne Web-APIs verwenden HTTP. RFC 9110 definiert die Semantik von HTTP als zustandsloses Protokoll auf Anwendungsebene und beschreibt unter anderem Ressourcen, Repräsentationen, Methoden und Statuscodes.

Die OpenAPI Specification ist dagegen kein Transportprotokoll, sondern ein standardisiertes, programmiersprachenunabhängiges Beschreibungsformat für HTTP-APIs. Eine OpenAPI-Beschreibung kann Endpunkte, Parameter, Datenschemata, Antworten und Sicherheitsverfahren dokumentieren und von Menschen sowie Werkzeugen verarbeitet werden.

Was gehört zu einem guten API-Vertrag?

• Operationen: Welche Aktionen sind möglich?
• Datenmodell: Welche Felder werden erwartet oder zurückgegeben?
• Validierung: Welche Eingaben sind zulässig?
• Fehlerfälle: Wie werden fehlende Rechte, ungültige Daten oder technische Fehler signalisiert?
• Authentifizierung und Autorisierung: Wer darf welche Operation ausführen?
• Versionierung: Wie werden Änderungen eingeführt, ohne bestehende Integrationen unnötig zu brechen?
• Betriebsgrenzen: Gibt es Rate Limits, Timeouts oder Größenbeschränkungen?

API ist nicht automatisch REST

REST ist ein Architekturstil mit spezifischen Constraints. Eine HTTP-Schnittstelle wird im Alltag häufig als „REST API“ bezeichnet, obwohl sie REST nur teilweise umsetzt. Neben REST existieren weitere API-Stile und Protokolle, beispielsweise GraphQL, RPC-orientierte Ansätze oder ereignisbasierte Schnittstellen.

Für die Architektur ist daher wichtiger, welche Eigenschaften der Geschäftsprozess benötigt, als welche Bezeichnung marketingwirksam klingt.

API und Webhook: zwei unterschiedliche Kommunikationsrichtungen

Bei einem klassischen API-Aufruf fragt ein Client aktiv Daten oder eine Aktion an. Ein Webhook dreht den Impuls häufig um: Das Quellsystem sendet bei einem Ereignis automatisch eine Nachricht an einen zuvor registrierten Empfänger.

Beispiel: Eine Anwendung kann per API regelmäßig prüfen, ob eine Bestellung bezahlt wurde. Alternativ kann der Zahlungsdienst bei erfolgreicher Zahlung einen Webhook senden. In komplexen Integrationen werden beide Muster häufig kombiniert.

Welche Sicherheitsfragen gehören dazu?

Eine API darf nicht allein deshalb als sicher gelten, weil sie nicht in einer Benutzeroberfläche sichtbar ist. Typische Themen sind:

• Authentifizierung,
• rollenbasierte oder objektbezogene Autorisierung,
• TLS-verschlüsselte Übertragung,
• Eingabevalidierung,
• Rate Limiting,
• Logging und Monitoring,
• Schutz sensibler Daten in Fehlerausgaben und Logs.

Praxisbeispiel

Ein Kundenportal soll den Auftragsstatus aus einem ERP anzeigen. Statt die ERP-Datenbank direkt aus dem Portal anzusprechen, kann das ERP eine API bereitstellen. Das Portal fragt nur die freigegebenen Auftragsdaten ab. Die interne Datenstruktur des ERP bleibt gekapselt und Berechtigungen können an der Schnittstelle kontrolliert werden.

API-Design ist auch Produktdesign

Eine Schnittstelle hat Nutzer – nur sind es Entwickler und andere Systeme. Gute APIs benötigen deshalb stabile Begriffe, nachvollziehbare Fehler, konsistente Ressourcenmodelle und dokumentierte Änderungsregeln. Eine technisch funktionierende API kann organisatorisch trotzdem schlecht sein, wenn jede Integration individuelles Wissen über versteckte Sonderfälle benötigt.

Für geschäftskritische APIs sollte zudem Ownership geklärt sein: Wer entscheidet über Änderungen? Wie lange werden Versionen unterstützt? Wie werden Consumer informiert? Solche Governance-Fragen verhindern, dass eine zunächst kleine Schnittstelle später zum schwer veränderbaren Integrationsengpass wird.

Fazit

APIs sind Verträge zwischen Softwaresystemen. Gute Schnittstellen reduzieren Kopplung, machen Integrationen nachvollziehbarer und schaffen eine Grundlage für Automatisierung. Entscheidend sind dabei nicht nur Endpunkte, sondern Datenmodell, Fehlerverhalten, Sicherheit, Versionierung und Dokumentation.