Eine Wetter-App ruft aktuelle Messwerte von einem Wetterdienst ab. Ein Shop übergibt Zahlungsinformationen an einen Zahlungsanbieter, eine Website bindet Kartenmaterial ein, ein Newsletter-Tool übernimmt neue Kontakte aus einem Formular und eine Buchhaltungssoftware importiert Rechnungsdaten. Hinter solchen Abläufen steht häufig eine API.
Eine API ist eine Programmierschnittstelle, über die unterschiedliche Programme, Dienste oder Systeme nach festgelegten Regeln miteinander kommunizieren können. Die Abkürzung steht für „Application Programming Interface“. Da der deutsche Bezugsbegriff „Schnittstelle“ feminin ist, lautet die korrekte Form eine API beziehungsweise die API.
Eine API ist nicht automatisch eine sichtbare Benutzeroberfläche. Menschen bedienen eine Website oder App über Schaltflächen, Formulare und Menüs. Programme nutzen dagegen definierte Schnittstellen, um Daten oder Funktionen anzufordern. Beide Ebenen können zur selben Anwendung gehören: Die Wetter-App zeigt Ihnen eine grafische Vorhersage, während sie die zugrunde liegenden Werte über eine API abruft.
Eine API verbindet Software – und ist nicht mit App, Datenbank oder Bibliothek identisch
Eine API lässt sich als technischer Vertrag verstehen. Dieser Vertrag legt fest, welche Daten oder Funktionen verfügbar sind, wie ein Programm sie anfordert, welche Eingaben zulässig sind und welche Antwort es erwarten darf. Die interne Umsetzung bleibt dabei verborgen. Ein Shop muss beispielsweise nicht wissen, wie ein Zahlungsanbieter Betrugsprüfungen, Konten oder Buchungen intern organisiert. Er muss lediglich die dokumentierten Anforderungen der Schnittstelle erfüllen.
Im Alltag ist häufig eine Web-API gemeint, die über ein Netzwerk und meist über HTTP erreichbar ist. Der Begriff reicht jedoch weiter. Ein Betriebssystem stellt Anwendungen APIs für Dateien, Fenster oder Geräte bereit. Eine Programmbibliothek veröffentlicht Klassen und Funktionen, die anderer Code aufrufen kann. Solche lokalen APIs benötigen weder einen entfernten Server noch eine Internetverbindung.
API, Oberfläche, Datenbank, Bibliothek und SDK sauber trennen
- Eine Benutzeroberfläche richtet sich an Menschen. Sie zeigt Informationen an und nimmt Eingaben per Maus, Tastatur oder Touch entgegen. Eine API richtet sich an Software.
- Eine Datenbank speichert und verwaltet Daten. Eine API kann den kontrollierten Zugriff darauf vermitteln, ist aber nicht selbst automatisch die Datenbank. Zwischen Schnittstelle und Datenbank können Geschäftslogik, Berechtigungsprüfungen und weitere Dienste liegen.
- Eine Bibliothek ist einbindbarer Programmcode. Die öffentlich nutzbaren Funktionen, Klassen und Parameter dieser Bibliothek bilden ihre API. Bibliothek und API bezeichnen daher nicht dieselbe technische Ebene.
- Ein SDK, kurz für Software Development Kit, bündelt Entwicklungswerkzeuge. Es kann Bibliotheken, Dokumentation, Beispiele, Testhilfen und Werkzeuge zur Nutzung einer oder mehrerer APIs enthalten. Das SDK erleichtert den Zugriff, während die API den eigentlichen Schnittstellenvertrag festlegt.
Nicht jede API ist eine REST-API
REST ist ein verbreiteter Architekturansatz für Web-APIs, aber keine allgemeine Definition des Begriffs API. Daneben existieren beispielsweise SOAP-basierte Schnittstellen und GraphQL-Dienste. Lokale Bibliotheks- und Betriebssystem-APIs folgen wiederum einer anderen Aufruflogik als ein Webdienst. Ebenso liefert nicht jede API JSON und nicht jede Kommunikation läuft über HTTP.
Entscheidend ist stets die Dokumentation der konkreten Schnittstelle. Sie beschreibt verfügbare Operationen, zulässige Eingaben, Antwortformate, Sicherheitsverfahren, Limits und Versionen. Bei HTTP-APIs kann eine maschinenlesbare OpenAPI-Beschreibung diese Bestandteile strukturiert erfassen. Sie ersetzt jedoch nicht die fachliche Erklärung, was eine Operation bewirkt und welche Geschäftsregeln gelten.
Vom Request zur Response: So funktionieren Endpunkt, REST, JSON und Webhook
Bei einer typischen Web-API sendet ein Client eine Anfrage an einen API-Dienst. Der Client kann eine App, ein Shop, ein Serverprozess oder ein anderes Programm sein. Die Anfrage heißt Request, die Antwort Response. Dazwischen prüft der Dienst Ziel, Eingaben, Zugangsdaten, Berechtigungen und technische Grenzen.
Ein Endpunkt besteht nicht nur aus einer URL
Ein Endpunkt einer HTTP-API ist ein adressierbarer Zugang zu einer bestimmten Operation. Dazu gehören mindestens die Serveradresse, ein Pfad und die vorgesehene HTTP-Methode. Der Pfad /v1/invoices allein beschreibt die Operation noch nicht vollständig: GET /v1/invoices kann Rechnungen abrufen, während POST /v1/invoices Daten zur Verarbeitung übermittelt. Welche Bedeutung tatsächlich gilt, legt der API-Vertrag fest.
Ein Request enthält eine Methode und ein Ziel. Hinzukommen können Pfadparameter, Query-Parameter, Header sowie ein Request Body. Parameter grenzen beispielsweise einen Zeitraum ein oder identifizieren eine Ressource. Header übermitteln Metadaten wie das Datenformat oder Zugangsdaten. Der Body enthält bei schreibenden Operationen häufig die eigentlichen Nutzdaten.
GET wird typischerweise zum Lesen verwendet, POST häufig zum Übermitteln oder Anstoßen einer Verarbeitung. PUT oder PATCH können Änderungen übertragen, DELETE kann eine Löschoperation auslösen. Diese Zuordnung ist eine verbreitete Konvention, aber kein Ersatz für die Dokumentation: Eine konkrete API bestimmt, welche Methoden ein Endpunkt akzeptiert und welche fachliche Wirkung sie haben.
REST ordnet die Architektur, JSON das Datenformat
REST beschreibt einen Architekturstil mit mehreren Bedingungen. Dazu gehören eine Trennung zwischen Client und Server, zustandslose Anfragen und eine einheitliche Schnittstelle für Ressourcen. Zustandslos bedeutet vereinfacht: Jeder Request enthält die Informationen, die der Dienst für seine Bearbeitung benötigt. Der Server darf nicht voraussetzen, dass notwendiger Kontext ausschließlich aus einem vorherigen Request bekannt ist.
Viele Anbieter verwenden den Ausdruck REST-API lockerer für ressourcenorientierte HTTP-Schnittstellen. REST legt jedoch weder JSON als einziges Datenformat fest noch ist jede HTTP-API automatisch REST-konform. JSON, HTTP und REST bezeichnen unterschiedliche Ebenen: JSON strukturiert Daten, HTTP transportiert Nachrichten und REST beschreibt Architekturprinzipien.
JSON macht strukturierte Daten maschinenlesbar
JSON ist ein textbasiertes Datenformat und keine Programmiersprache. Ein Objekt enthält Schlüssel-Wert-Paare, ein Array eine geordnete Liste. Als Werte sind unter anderem Zeichenketten, Zahlen, Wahrheitswerte, null, weitere Objekte und Arrays möglich. Verschachtelte Objekte bilden zusammengehörende Angaben ab.
Ein vereinfachter Rechnungsdatensatz könnte so aussehen: {"invoiceNumber":"RE-2026-1042","amount":249.90,"paid":false,"items":["Beratung","Versand"],"customer":{"id":4815,"country":"DE"}}. Das Beispiel enthält Schlüssel-Wert-Paare, ein Array und ein verschachteltes Kundenobjekt.
Ein fehlendes Anführungszeichen oder Komma kann das JSON syntaktisch unlesbar machen. Davon zu trennen ist die Datenvalidierung: Das Dokument kann korrektes JSON sein und trotzdem gegen den API-Vertrag verstoßen, etwa weil ein Pflichtfeld fehlt, eine Zahl als Text übertragen wurde oder ein Rechnungsbetrag negativ sein darf, die konkrete Geschäftsregel dies aber untersagt. JSON Schema kann solche Typen und Strukturregeln beschreiben; zusätzliche fachliche Prüfungen bleiben möglich.
Vollständiger API-Aufruf am Beispiel eines Rechnungsimports
Das folgende Beispiel ist ausdrücklich fiktiv. Ein Buchhaltungssystem sendet einen authentifizierten Request an POST https://api.example.invalid/v1/invoices. Es setzt Content-Type: application/json, überträgt einen Platzhalter wie Authorization: Bearer TOKEN und sendet Rechnungsdaten im Body. Ein erfolgreicher Dienst könnte mit 201 Created und einem JSON-Objekt antworten, das die neue Rechnungs-ID und den Verarbeitungsstatus enthält.
| Station | Angabe des Clients | Prüfung durch den Dienst | Erfolg oder typischer Fehler |
|---|---|---|---|
| Ziel und Methode | POST, Serveradresse, Version und Pfad /v1/invoices | Existieren Pfad und Version, und ist POST für diese Ressource vorgesehen? | Der Request wird weitergeleitet. Ein falscher Pfad kann 404, eine nicht erlaubte Methode 405 auslösen. |
| Header | Content-Type: application/json und gegebenenfalls weitere Pflichtheader | Entsprechen Medientyp, Zeichencodierung und geforderte Metadaten dem Vertrag? | Der Body wird als JSON behandelt. Ein fehlender oder falscher Content-Type kann zur Ablehnung führen. |
| Authentifizierung | API-Key oder Authorization: Bearer TOKEN als geschützter Platzhalter | Fehlen Zugangsdaten, sind sie abgelaufen oder ungültig? | Die Identität beziehungsweise Kennung wird akzeptiert. Andernfalls ist 401 eine typische Reaktion. |
| Autorisierung | Token mit den vorgesehenen Rechten oder Scopes | Darf der identifizierte Client Rechnungen importieren? | Die Verarbeitung geht weiter. Fehlende Rechte können trotz gültiger Zugangsdaten zu 403 führen. |
| Rate Limit | Request innerhalb der vereinbarten Quote | Wurde das Zeit-, Mengen- oder Kostenlimit überschritten? | Der Request wird zugelassen. Bei zu vielen Anfragen kann 429 und optional ein Retry-After-Hinweis folgen. |
| JSON-Parsing | Syntaktisch korrektes JSON im Request Body | Sind Klammern, Kommas, Zeichenketten und Werte lesbar? | Der Dienst erhält eine Datenstruktur. Kaputtes JSON führt häufig zu 400, abhängig von der API. |
| Datenvalidierung | Rechnungsnummer, Betrag, Währung und weitere Pflichtfelder | Stimmen Felder, Datentypen, Wertebereiche und Geschäftsregeln? | Die Daten sind verarbeitbar. Ungültige Inhalte können je nach Vertrag etwa 400 oder 422 ergeben. |
| Verarbeitung | Vollständig geprüfte Rechnungsdaten | Kann der Dienst den Datensatz speichern, zuordnen oder an ein Folgesystem übergeben? | Die Rechnung wird angelegt. Konflikte oder interne Fehler können weitere dokumentierte Codes erzeugen. |
| Response | Keine neue Eingabe; der Client wartet auf die Antwort | Welcher Statuscode, welche Header und welcher Response Body beschreiben das Ergebnis? | Beispielsweise 201 plus JSON mit ID und Status. Bei Fehlern liefern Body, Fehlercode und Request-ID oft die genauere Ursache. |
Ein Webhook dreht die Initiierungsrichtung um
Beim üblichen API-Aufruf fragt der Client aktiv an. Ein Webhook übermittelt Daten dagegen ereignisgesteuert an eine zuvor registrierte Empfänger-URL. Ein Zahlungsdienst kann beispielsweise nach einer bestätigten Zahlung selbst einen HTTP-Request an den Shop senden. Dadurch muss der Shop den Status nicht ständig per Polling abrufen.
Prüfen Sie bei Webhooks die Anbieterdokumentation zu Signaturen, geheimen Schlüsseln, Wiederholungsversuchen und möglichen Mehrfachzustellungen. Der Empfänger sollte die Herkunft und Unversehrtheit prüfen und dasselbe Ereignis bei erneuter Zustellung nicht ungewollt doppelt verbuchen. Ein universelles Signatur- oder Retry-Verfahren existiert nicht.
API-Zugriff absichern und Fehler systematisch einordnen
Authentifizierung, Autorisierung und Zugangsdaten erfüllen verschiedene Aufgaben
Die Authentifizierung prüft eine behauptete Identität oder vorgelegte Zugangsinformation. Die Autorisierung entscheidet anschließend, welche Ressourcen und Aktionen erlaubt sind. Deshalb kann ein Request gültige Zugangsdaten enthalten und dennoch abgelehnt werden: Der Client ist bekannt, besitzt aber nicht die erforderliche Berechtigung.
Ein API-Key ist eine anbieterabhängige Kennung oder Zugangsinformation. Er kann ein Projekt identifizieren, Quoten und Abrechnung zuordnen oder den Zugriff begrenzen. Ein gewöhnlicher API-Key authentifiziert jedoch nicht zwangsläufig eine konkrete Person oder Anwendung im strengen sicherheitstechnischen Sinn. Seine Bedeutung ergibt sich aus der Dokumentation.
Ein Token ist allgemein eine übertragene Zugriffsberechtigung. OAuth 2.0 ist dagegen ein Autorisierungsframework: Ein Client kann begrenzte Rechte erhalten, ohne das Passwort einer Nutzerin oder eines Nutzers an jeden angebundenen Dienst weiterzugeben. Ein Autorisierungsserver stellt dafür ein Access Token aus, das der Client beim Resource Server verwendet. Scopes können festlegen, ob der Zugriff beispielsweise nur das Lesen von Kontakten oder zusätzlich deren Änderung erlaubt.
Behandeln Sie API-Keys, Tokens und Webhook-Secrets wie Passwörter beziehungsweise andere Geheimnisse. Veröffentlichen Sie sie nicht im Quellcode oder in öffentlichen Repositories, schreiben Sie sie nicht unnötig in URLs oder Protokolle und übertragen Sie sie nur verschlüsselt. Bearer Tokens sind besonders kritisch: Wer ein solches Token besitzt, kann es grundsätzlich im Rahmen seiner Rechte verwenden. Bei einem vermuteten Leak müssen Zugangsdaten widerrufen oder rotiert werden.
Statuscodes zeigen die Fehlerklasse, nicht immer die vollständige Ursache
400 Bad Request weist auf einen Request hin, den der Dienst wegen seiner Form oder seines Inhalts nicht korrekt verarbeiten kann. Prüfen Sie Parameter, Header und JSON. Für syntaktisch verständliche, aber fachlich nicht verarbeitbare Inhalte verwenden manche APIs 422 Unprocessable Content. Eine universelle Zuordnung zwischen JSON-Fehlern und diesen Codes gibt es nicht.
401 Unauthorized bedeutet typischerweise, dass gültige Authentifizierungsdaten fehlen. Prüfen Sie API-Key, Token, Ablaufzeit und Authentifizierungsschema. 403 Forbidden bedeutet, dass der Server den Request verstanden hat, ihn aber nicht erfüllen will. Hier sind häufig Rechte, Rollen oder Scopes entscheidend. Neue Zugangsdaten beheben 403 nicht, wenn die erforderliche Berechtigung weiterhin fehlt.
404 Not Found kann auf einen falschen Pfad, eine unbekannte Ressource oder eine nicht offengelegte Ressource hindeuten. 405 Method Not Allowed zeigt, dass der Server die Methode kennt, sie am angesprochenen Ziel aber nicht unterstützt. 429 Too Many Requests steht für zu viele Anfragen innerhalb eines Zeitraums. Prüfen Sie bei 429 Quote, Zeitfenster, Parallelität und einen gegebenenfalls vorhandenen Retry-After-Hinweis, statt sofort den API-Key auszutauschen.
Lesen Sie neben dem Statuscode immer den Response Body und den Content-Type. Viele APIs ergänzen einen dokumentierten Fehlercode, eine Beschreibung, betroffene Felder und eine Request- oder Instanz-ID. Für strukturierte Problemdetails existiert unter anderem das Format application/problem+json. Der Statuscode liefert die grobe Kategorie; die konkrete Ursache steht häufig im Antwortinhalt.
CORS, API-Version und Rate Limit getrennt prüfen
CORS kontrolliert im Browser, ob JavaScript eine Antwort von einem anderen Ursprung verwenden darf. Eine API kann erreichbar sein und denselben Request aus einer Serveranwendung oder einem Kommandozeilenwerkzeug beantworten, während der Browser die Antwort blockiert. Prüfen Sie Browserkonsole, Netzwerkprotokoll, Origin, Antwortheader und eine mögliche OPTIONS-Preflight-Anfrage. Ein beliebiger zusätzlicher Client-Header behebt eine fehlende Serverfreigabe nicht.
Eine geänderte API-Version kann bisher funktionierende Integrationen ebenfalls brechen. Anbieter wählen Versionen je nach Schnittstelle über Pfade, Query-Parameter, Header oder andere Vertragsbestandteile aus. Prüfen Sie die konfigurierte Version, das Änderungsprotokoll, Deprecation-Hinweise und die Version eines verwendeten SDKs. Rate Limits sind ebenso anbieter- und teilweise endpointabhängig; verlassen Sie sich nicht auf bestimmte Quoten oder Headernamen, wenn sie nicht dokumentiert sind.
Fehlgeschlagenen API-Aufruf in sinnvoller Reihenfolge prüfen
- Vergleichen Sie die tatsächliche Serveradresse, den Pfad und die HTTP-Methode mit der Dokumentation.
- Prüfen Sie API-Version, Auslaufhinweise und gegebenenfalls die Version des SDKs oder der Clientbibliothek.
- Kontrollieren Sie Pflichtheader, Content-Type, Parameter und die korrekte Platzierung eines Request Bodys.
- Prüfen Sie API-Key oder Token auf Gültigkeit, Ablauf, sichere Übertragung und das geforderte Authentifizierungsschema.
- Vergleichen Sie Rollen, Berechtigungen und OAuth-Scopes mit der angeforderten Operation.
- Validieren Sie zuerst die JSON-Syntax und danach Pflichtfelder, Datentypen, erlaubte Werte sowie Geschäftsregeln.
- Lesen Sie Statuscode, Response Body, Content-Type, dokumentierten Fehlercode und Request-ID gemeinsam.
- Prüfen Sie bei 429 die konkrete Quote und bei Browserproblemen CORS, Origin und Preflight-Anfrage.
Häufige Fragen zur API
Was ist eine API?
Eine API ist eine Programmierschnittstelle, über die Programme, Dienste oder Systeme nach festgelegten Regeln Daten austauschen oder Funktionen aufrufen können.
Warum sagt man eine API?
API steht für Application Programming Interface und wird im Deutschen als Programmierschnittstelle beziehungsweise Schnittstelle verstanden. Da „Schnittstelle“ feminin ist, lautet die Form eine API oder die API.
Was ist ein API-Endpunkt?
Bei einer Web-API ist ein Endpunkt ein adressierbarer Zugang zu einer Operation. Serveradresse, Pfad und vorgesehene Methode gehören zusammen; der Pfad allein beschreibt die Funktion nicht vollständig.
Was ist REST?
REST ist ein Architekturstil für verteilte Systeme und wird häufig bei HTTP-APIs eingesetzt. Kennzeichnend sind unter anderem Client-Server-Trennung, zustandslose Anfragen und eine einheitliche Schnittstelle. Nicht jede API ist eine REST-API.
Was ist JSON?
JSON ist ein textbasiertes Format für strukturierte Daten. Es unterstützt Objekte mit Schlüssel-Wert-Paaren, Arrays, Zeichenketten, Zahlen, Wahrheitswerte und null. Syntaktisch korrektes JSON kann dennoch fachlich ungültige Daten enthalten.
Was ist ein API-Key?
Ein API-Key ist eine vom Anbieter vergebene Kennung oder Zugangsinformation. Er kann Zugriffe beschränken sowie Projekte, Quoten oder Kosten zuordnen, authentifiziert aber nicht zwangsläufig eine Person. Schützen Sie ihn wie andere Zugangsdaten.
Was ist ein Webhook?
Ein Webhook sendet bei einem abonnierten Ereignis automatisch einen HTTP-Request an eine registrierte Empfänger-URL. Im Unterschied zum Polling muss der Empfänger nicht regelmäßig nach neuen Daten fragen.
Warum antwortet eine API mit einem Fehlercode?
Fehlercodes liefern dem Client eine maschinenlesbare Kategorie, etwa für fehlende Zugangsdaten, unzureichende Rechte, ein unbekanntes Ziel oder ein überschrittenes Limit. Der Response Body ergänzt häufig die konkrete Ursache und den nächsten sinnvollen Prüfschritt.
Prüfen Sie bei einer Integration zuerst die Dokumentation und die verwendete API-Version, danach Endpunkt und Methode, anschließend Header und Zugangsdaten sowie zuletzt Datenformat, Statuscode und Response-Details. Eine API ermöglicht kontrollierten Zugriff auf Daten und Funktionen. Stabil und sicher bleibt dieser Zugriff jedoch nur mit begrenzten Berechtigungen, geschützten Geheimnissen, nachvollziehbarer Versionierung und einer Fehlerbehandlung, die nicht beim Statuscode endet.
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten