EMZETT.API
Kurz: Application Programming Interface — eine definierte Schnittstelle, über die zwei Programme miteinander kommunizieren, ohne die jeweilige interne Implementierung zu kennen.
Genauer: Legt fest, welche Funktionen/Endpunkte verfügbar sind, welche Daten man senden muss und welche man zurückbekommt. Im Web meist als HTTP-Schnittstelle umgesetzt, häufig nach dem REST-Prinzip. Eine gute API versteckt Komplexität hinter einer stabilen, dokumentierten Oberfläche.
Im Detail
APIs auf verschiedenen Ebenen
APIs gibt es auf verschiedenen Ebenen: Eine Library-API (z. B. eine Funktion in einer Programmiersprachen-Bibliothek) wird direkt im Code aufgerufen, ohne Netzwerkkommunikation. Eine Web-API wird über das Netzwerk angesprochen — meist per HTTP-Request an eine URL, mit strukturierten Antworten im JSON- oder XML-Format. Eine Betriebssystem-API (Systemaufrufe) erlaubt Programmen, mit dem darunterliegenden Betriebssystem zu kommunizieren (Datei öffnen, Speicher anfordern). Alle drei teilen dasselbe Grundprinzip: eine feste, dokumentierte Schnittstelle, hinter der sich beliebig komplexe interne Logik verbergen kann.
curl -X GET https://api.beispiel.de/v1/kunden/42 \
-H "Authorization: Bearer <token>"
curl -X POST https://api.beispiel.de/v1/bestellungen \
-H "Content-Type: application/json" \
-d '{"produkt_id": 7, "menge": 2}'Versionierung
Ein zentrales Konzept beim API-Design ist Versionierung (/v1/, /v2/): Ändert sich die API grundlegend (z. B. ein Feld wird umbenannt oder entfernt), sollen bestehende Nutzer nicht sofort brechen — deshalb bleiben alte Versionen oft parallel eine Zeit lang erreichbar, während neue Clients bereits die neue Version nutzen. Manche APIs versionieren stattdessen über HTTP-Header statt über die URL, das grundlegende Prinzip (Abwärtskompatibilität wahren) bleibt aber dasselbe.
Dokumentation und Verträge
Eine gut dokumentierte API (z. B. über eine OpenAPI/Swagger-Spezifikation, ein standardisiertes maschinenlesbares Format) beschreibt jeden Endpunkt, jeden erwarteten Parameter, jeden möglichen Fehlercode und das genaue Antwortformat, damit andere Entwickler sie nutzen können, ohne den internen Quellcode zu kennen. Aus einer OpenAPI-Spezifikation lassen sich außerdem automatisch interaktive Dokumentationsseiten, Client-Code (siehe SDK) und sogar Testfälle generieren — die Spezifikation wird zum “Vertrag” zwischen API-Anbieter und -Nutzer.
Authentifizierung
Die meisten öffentlichen APIs erfordern eine Form der Authentifizierung, meist per API-Key (ein geheimer Token im Header) oder OAuth (für Zugriff im Namen eines Nutzers, z. B. “melde dich mit deinem Google-Konto an”) — ohne diese Absicherung könnte jeder unbegrenzt Anfragen stellen, was sowohl Kosten als auch Missbrauchsrisiken verursacht.
Rate Limiting und Fehlerbehandlung
APIs mit öffentlichem Zugriff begrenzen üblicherweise, wie viele Anfragen ein Client in einem Zeitfenster stellen darf (“Rate Limiting”) — ohne diese Begrenzung könnte ein einzelner fehlerhafter oder böswilliger Client die gesamte Infrastruktur überlasten. Wird das Limit überschritten, antwortet die API typischerweise mit HTTP-Status 429 (“Too Many Requests”) statt die Anfrage einfach zu ignorieren, damit der aufrufende Client den Fehler erkennen und entsprechend reagieren kann (z. B. mit exponentiellem Backoff — nach dem ersten Fehler kurz warten, bei wiederholtem Fehler die Wartezeit verdoppeln).
GraphQL als Alternative zu REST
Neben klassischen REST-APIs hat sich GraphQL als Alternative etabliert, bei der der Client in einer einzigen Anfrage exakt festlegt, welche Felder er benötigt, statt wie bei REST auf vordefinierte, oft überladene Endpunkte angewiesen zu sein. Das reduziert sowohl Über- als auch Unterfetching von Daten (zu viele bzw. zu wenige Felder pro Antwort), erhöht aber die Komplexität auf Serverseite, da die Flexibilität der Abfragen aktiv verwaltet werden muss (z. B. gegen zu teure, verschachtelte Abfragen).