Was ist eine API (Programmierschnittstelle)?

Eine API ist ein Regelwerk, mit dem eine Anwendung Daten und Funktionen einer anderen anfordern kann, ohne deren internen Code zu kennen. Die bekannte Restaurant-Analogie – Sie bestellen von der Karte, die Küche bleibt unsichtbar – verdient genau einen Satz und nicht mehr, denn das Original ist lehrreicher als die Metapher: Eine API ist ein Vertrag, und Verträge sind präzise.

Das Wichtigste in Kürze

Anatomie einer HTTP-API-Anfrage und -Antwort

Kaum eine Erklärung zeigt eine vollständige, deshalb hier ein ganzer API-Aufruf – Anfrage und Antwort, nichts ausgelassen:

POST /classes/Todo HTTP/1.1              ← Methode + Endpoint
Host: api.example-backend.com
X-Api-Key: app-7f2c…                     ← identifiziert die aufrufende App
Authorization: Bearer eyJhbGci…          ← authentifiziert den Benutzer
Content-Type: application/json

{ "title": "Ship the release", "done": false }

HTTP/1.1 201 Created                     ← Status: erfolgreich, Ressource angelegt
Location: /classes/Todo/xKd91m
Content-Type: application/json

{ "objectId": "xKd91m", "createdAt": "2026-07-24T10:30:00Z" }

Derselbe Aufruf über ein SDK – das nichts anderes ist als genau dieses HTTP, verpackt in die Idiome Ihrer Sprache:

// JavaScript / Node.js — Back4app JS SDK
// One API call: create a record via the auto-generated REST API
const todo = new Parse.Object('Todo');
todo.set('title', 'Ship the release');
todo.set('done', false);
await todo.save();
// Under the hood: POST /classes/Todo with a JSON body → 201 Created
console.log('Created with id', todo.id);

// Flutter / Dart — Back4app Flutter SDK
// One API call: create a record via the auto-generated REST API
final todo = ParseObject('Todo')
  ..set('title', 'Ship the release')
  ..set('done', false);
await todo.save();
// Under the hood: POST /classes/Todo with a JSON body → 201 Created
print('Created with id ${todo.objectId}');

// iOS / Swift — Back4app Swift SDK
// One API call: create a record via the auto-generated REST API
var todo = Todo()
todo.title = "Ship the release"
todo.done = false
todo.save { result in
    // Under the hood: POST /classes/Todo with a JSON body → 201 Created
    if case .success(let saved) = result { print("Created with id \(saved.id ?? "")") }
}

// Android / Kotlin — Back4app Android SDK
// One API call: create a record via the auto-generated REST API
val todo = ParseObject("Todo")
todo.put("title", "Ship the release")
todo.put("done", false)
todo.saveInBackground { e ->
    // Under the hood: POST /classes/Todo with a JSON body → 201 Created
    if (e == null) println("Created with id ${todo.objectId}")
}

So funktioniert ein API-Aufruf

Drei Eigenschaften dieser Schleife erklären, warum APIs den modernen Stack tragen. Abstraktion: Der Aufrufer braucht den Vertrag, nie die Implementierung – der Anbieter kann hinter der Schnittstelle alles neu schreiben, ohne einen einzigen Client zu brechen. Grenze: Validierung und Berechtigungen sitzen an der Schnittstelle. Deshalb sprechen Clients mit APIs und nie direkt mit der Datenbank – eine API ist keine Datenbank, sondern der Türsteher davor. Komposition: Weil jede Fähigkeit aufrufbar ist, setzen sich Anwendungen aus Diensten zusammen – Authentifizierung von hier, Zahlungen von dort, Karten von einem dritten Anbieter. Und zunehmend nutzen KI-Agenten dasselbe Fundament: Tool Calling ist API-Aufrufen, bei dem ein Modell über die Anfragen entscheidet.

Der Vertrag: was eine API tatsächlich zusagt

Die Seiten, die eine API “einen Vertrag” nennen, zeigen selten einen. Heute ist der Vertrag ein maschinenlesbares Dokument – die OpenAPI Specification ist der Standard für HTTP-APIs –, das jeden Endpoint, jeden Parameter, jedes Schema und jeden Statuscode auflistet. Aus dieser einen Datei generieren Werkzeuge Referenzdokumentation, Client-Bibliotheken, Server-Stubs, Mock-Server und Vertragstests.

Das Bild vom Vertrag hat Biss, weil es um Versionierung geht. Ein zusätzliches Antwortfeld bricht niemanden; ein umbenanntes oder entferntes Feld bricht jeden Konsumenten, und zwar lautlos. Ausgereifte APIs unterscheiden deshalb zwischen additiven und inkompatiblen Änderungen, versionieren ihre Oberfläche (/v1/ oder über Header) und veröffentlichen Deprecation-Fristen. Eine API ohne Änderungsrichtlinie ist ein Vertrag ohne Bedingungen: formal ein Versprechen, praktisch eine Überraschung.

Die Arten von APIs

Nach Suchanfragen gegliedert, denn “Arten von APIs” ist eine eigene Suche: Es gibt zwei Taxonomien, nicht eine.

Nach Zielgruppe:

Nach Stil: REST (Ressourcen unter URLs, HTTP-Methoden), GraphQL (vom Client geformte Abfragen an einem Endpoint), gRPC (binär, Contract-first, Service-zu-Service), SOAP (XML-Envelopes, Enterprise- und Legacy-Standards) und WebSocket-APIs (bidirektional, persistent) – verglichen in der nächsten Tabelle.

Und ein Absatz, den die Web-Erklärungen auslassen: Nicht jede API ist eine Web-API. Die Standardbibliothek einer Sprache, POSIX-Systemaufrufe sowie die eingebauten Schnittstellen fetch und Geolocation eines Browsers sind allesamt APIs – Verträge zwischen Programmen –, die nie ein Netzwerk überqueren. Die Web-Variante hat den Vertrag lediglich hinter eine URL gelegt.

REST vs. GraphQL vs. gRPC vs. SOAP vs. WebSocket

Typische Anwendungsfälle

• Mobile und Web-Backends – die Daten jedes Screens kommen über eine API; das Frontend berührt die Datenbank nie.
• Integration von Drittanbietern – Zahlungen, Identität, Messaging, Karten: Fähigkeiten, die per Vertrag gemietet statt neu gebaut werden.
• Kommunikation zwischen Microservices – interne APIs als Nahtstellen, an denen Dienste unabhängig deployt und skaliert werden.
• Automatisierung und Skripting – alles mit einer API lässt sich orchestrieren: CI-Pipelines, Infrastruktur, Content-Workflows.
• KI-Agenten und Tool Calling – Modelle handeln, indem sie APIs aufrufen; ein gut dokumentierter Vertrag wird heute doppelt maschinell genutzt, von SDKs und von Agenten.

Welchen API-Stil sollten Sie wählen? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Ein Vertrag bindet auch den Anbieter. Jedes veröffentlichte Feld wird zu etwas, auf das sich jemand verlässt; Weiterentwicklung gelingt über Disziplin bei der Versionierung, nicht über stille Änderungen.
• Netzwerk-APIs erben das Netzwerk. Latenz, Teilausfälle und Wiederholungsversuche gehören zur Semantik jedes entfernten Aufrufs – lokale Funktionsaufrufe brauchten nie Timeout-Richtlinien.
• Abstraktion verbirgt Kosten. Ein harmlos aussehender Aufruf kann teure Arbeit nach sich ziehen; Konsumenten sehen die Karte, nicht die Rechnung der Küche – genau dafür gibt es Rate Limits und Kontingente.
• Die Angriffsfläche wächst mit der Oberfläche. Jeder Endpoint ist eine Tür; Schlüssel identifizieren, autorisieren aber nicht. Echte Authentifizierung (Tokens nach OAuth 2.0, Berechtigungen pro Benutzer) und Eingabevalidierung sind Pflicht.
• Feste Strukturen passen nicht zu jedem Konsumenten. Die Trade-offs von Over- und Underfetching beim Endpoint-Design sind ein eigenes Thema – siehe den Schwesterartikel.

APIs mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Der entscheidende Unterschied: Die API wird generiert, nicht gebaut. Sie definieren ein Datenmodell, und die Plattform stellt es sofort als REST-Endpoints und GraphQL-Schema bereit – der oben zerlegte Aufruf ist echtes Back4app-Wire-Format –, wobei Schlüssel, Benutzer-Tokens und Berechtigungen auf Klassenebene den Vertrag an der Grenze durchsetzen. Die SDKs nutzen diese API idiomatisch auf jeder wichtigen Plattform, und eigene Operationen werden zu Cloud-Code-Funktionen: neue Endpoints in einer Datei, dieselbe Vertragsdisziplin, kein Server zu betreiben.