Was ist eine API?

Die API als Kellner

Stell dir ein Restaurant vor: Du (die App) bestellst beim Kellner (die API), der die Bestellung an die Küche (den Server) weitergibt und dir das Essen (die Daten) bringt. Du musst nicht wissen, wie die Küche funktioniert — du nutzt nur die definierte Schnittstelle.

REST-APIs und HTTP-Methoden

• GET — Daten abrufen
• POST — neue Daten anlegen
• PUT / PATCH — Daten ändern
• DELETE — Daten löschen

const res = await fetch("https://api.beispiel.de/produkte");
const produkte = await res.json();
console.log(produkte);

Statuscodes: die Sprache der Antwort

Jede Antwort einer API enthält einen HTTP-Statuscode, der in einer Zahl zusammenfasst, wie die Anfrage verlaufen ist. Codes im 200er-Bereich bedeuten Erfolg (200 „OK“, 201 „angelegt“). Der 400er-Bereich signalisiert Fehler auf Seiten des Aufrufers (404 „nicht gefunden“, 401 „nicht angemeldet“, 403 „nicht erlaubt“). Der 500er-Bereich steht für Fehler auf dem Server. Wer diese Codes kennt, kann Probleme viel schneller einordnen — sie sind der erste Blick bei jeder Fehlersuche.

Wer darf was? Authentifizierung

Viele APIs liefern nicht jedem beliebig Daten. Sie verlangen einen Nachweis, wer da anfragt — meist über einen API-Schlüssel oder ein Token, das mit jeder Anfrage mitgeschickt wird. Der Server prüft dieses Merkmal und entscheidet, ob und welche Daten er herausgibt. Genau deshalb dürfen solche Schlüssel niemals offen im Browser-Code stehen: Sie gehören auf den Server, wo Unbefugte nicht herankommen.

Mehr als REST: GraphQL und Webhooks

REST ist der verbreitetste Stil, aber nicht der einzige. Bei GraphQL fragt der Aufrufer in einer einzigen Anfrage genau die Felder ab, die er braucht — praktisch, wenn Oberflächen sehr unterschiedliche Datenmengen benötigen. Webhooks drehen das Prinzip um: Statt dass die App ständig nachfragt, meldet sich die API von selbst, sobald ein Ereignis eintritt, etwa eine neue Bestellung. Welcher Ansatz passt, hängt davon ab, wie und wie oft Daten fließen.

Was eine API gut benutzbar macht

Eine Schnittstelle ist ein Vertrag — und der sollte vorhersehbar sein. Gute REST-APIs benennen Ressourcen einheitlich und im Plural (/produkte, /bestellungen), verwenden für gleiche Dinge immer dieselbe Struktur und liefern große Ergebnismengen in Seiten aus, statt zehntausend Datensätze auf einmal zu schicken. Weil sich Anforderungen ändern, versieht man eine öffentliche API zusätzlich mit einer Version im Pfad, etwa /v1, damit bestehende Aufrufer nicht plötzlich brechen. Und weil niemand raten will, welche Felder es gibt, gehört eine Dokumentation dazu — häufig maschinenlesbar als OpenAPI-Beschreibung, aus der sich Beispiele und Testwerkzeuge automatisch erzeugen lassen.

Grenzen, Fehler und Ausfälle einplanen

Fremde APIs sind nie garantiert erreichbar, und genau darauf muss der eigene Code vorbereitet sein. Viele Anbieter begrenzen die Zahl der Anfragen pro Zeitraum und antworten bei Überschreitung mit dem Status 429. Sinnvoll ist dann kein sofortiger neuer Versuch, sondern ein Wiederholen mit wachsender Wartezeit. Ebenso wichtig sind Zeitlimits: Eine Anfrage, die nie beantwortet wird, darf nicht die ganze Anwendung blockieren. Bei schreibenden Aufrufen hilft Idempotenz — die Eigenschaft, dass ein versehentlich doppelt gesendeter Aufruf nicht zwei Bestellungen erzeugt. Wer diese Fälle von Anfang an bedenkt, baut Anwendungen, die auch bei Störungen kontrolliert reagieren.

Eine fremde API erkunden

Vor der ersten Codezeile steht immer dasselbe Vorgehen. Zuerst klärt die Dokumentation, welche Endpunkte es gibt, wie man sich ausweist und ob es eine Testumgebung mit eigenen Schlüsseln gibt — in ihr lässt sich gefahrlos ausprobieren, ohne echte Bestellungen oder Zahlungen auszulösen. Danach ruft man einen Endpunkt einmal von Hand auf, per Kommandozeile oder mit einem API-Werkzeug, und sieht sich die Antwort in Ruhe an: Welche Felder kommen zurück, wie sind Datum und Beträge formatiert, was passiert bei einem absichtlich falschen Aufruf? Erst wenn diese Fragen geklärt sind, lohnt es sich, die Anbindung zu programmieren.