Wenn du dich mit App-Entwicklung oder Webentwicklung beschäftigst, kommst du an einem Begriff nicht vorbei: API. Das steht für "Application Programming Interface", auf Deutsch Programmierschnittstelle. Klingt sperrig, ist aber ein Konzept, das du in fünf Minuten verstehen kannst. Ich zeig dir wie.
Video: Was ist eine API?

Kurz zusammengefasst
- Eine API (Programmierschnittstelle) ist eine standardisierte Schnittstelle, über die zwei Programme miteinander kommunizieren
- APIs funktionieren nach dem Request-Response-Prinzip: Du fragst etwas an, du bekommst eine Antwort
- Die drei wichtigsten API-Typen sind REST, GraphQL und SOAP
- Ohne APIs wäre moderne App-Entwicklung unmöglich - sie verbinden Frontend, Backend und externe Dienste
- Du benutzt täglich dutzende APIs, ohne es zu merken
Der Kellner im Restaurant
Bevor wir technisch werden, ein Bild das sofort klickt.
Stell dir ein Restaurant vor. Du sitzt am Tisch und hast Hunger. In der Küche stehen die Köche und können jedes Gericht zubereiten. Aber du kannst nicht einfach in die Küche laufen und dir selbst was kochen. Du brauchst einen Vermittler: den Kellner.
Der Kellner nimmt deine Bestellung auf, bringt sie in die Küche, wartet bis das Essen fertig ist und bringt es dir an den Tisch. Er ist die Schnittstelle zwischen dir und der Küche.
Genau das ist eine API. Sie ist der Kellner zwischen zwei Softwaresystemen.
- Du (der Gast) = das Programm, das Daten braucht (z.B. eine App)
- Die Küche = das System, das Daten hat (z.B. ein Server oder eine Datenbank)
- Der Kellner = die API, die Anfragen entgegennimmt und Antworten zurückbringt
Du musst nicht wissen, wie die Küche funktioniert. Du musst nicht wissen, welche Töpfe benutzt werden oder woher die Zutaten kommen. Du sagst dem Kellner, was du willst, und er kümmert sich um den Rest. Genauso musst du bei einer API nicht wissen, wie das andere System intern funktioniert. Du schickst eine Anfrage, du bekommst eine Antwort.
Was ist eine API genau?
Eine API - oder auf Deutsch Programmierschnittstelle - ist ein definierter Satz von Regeln und Protokollen, über den verschiedene Softwareprogramme miteinander kommunizieren können. Man spricht auch von einem "software to software interface", weil es nicht um die Kommunikation zwischen Mensch und Computer geht, sondern zwischen Computer und Computer.
Stell dir vor, du baust eine Wetter-App. Du willst das aktuelle Wetter in Berlin anzeigen. Du könntest jetzt selbst eine Wetterstation aufstellen, Sensoren auslesen und die Daten verarbeiten. Oder du nutzt eine Wetter-API. Die sagt: "Schick mir den Städtenamen, und ich schicke dir Temperatur, Luftfeuchtigkeit und Vorhersage zurück."
Das ist der Kern von API Programmierung: Du nutzt bestehende Systeme, statt alles selbst zu bauen.
Jede API hat eine Dokumentation - quasi die Speisekarte des Restaurants. Da steht drin:
- Welche Anfragen du stellen kannst (Endpoints)
- Welche Daten du mitschicken musst (Parameter)
- Was du als Antwort bekommst (Response)
- Welche Regeln gelten (Authentifizierung, Limits)
Wenn du dich fragst, wie Frontend und Backend miteinander kommunizieren - die Antwort ist in den meisten Fällen: über eine API.
Wie funktioniert eine API?
Das Grundprinzip ist simpel: Request und Response. Anfrage und Antwort.
Schritt 1: Der Request
Dein Programm (der Client) schickt eine Anfrage an die API. Diese Anfrage enthält:
- Die URL (wohin die Anfrage geht, z.B.
https://api.wetter.de/berlin) - Die Methode (was du tun willst: Daten holen, erstellen, ändern oder löschen)
- Optional: Daten (z.B. Suchbegriffe, Filter, Authentifizierung)
Schritt 2: Die Verarbeitung
Der Server empfängt die Anfrage, prüft ob du berechtigt bist, verarbeitet die Anfrage und bereitet die Antwort vor. Das ist die Küche, die dein Gericht zubereitet.
Schritt 3: Die Response
Der Server schickt eine Antwort zurück. Die enthält:
- Einen Statuscode (200 = alles gut, 404 = nicht gefunden, 500 = Serverfehler)
- Die Daten (meistens im JSON-Format)
Das wars. So einfach ist das Grundprinzip. Jede API, egal wie komplex, basiert auf diesem Muster. In meinem Artikel über das Backend meiner Production App siehst du, wie APIs in einer echten Architektur zusammenspielen.
Die HTTP-Methoden
Bei REST APIs gibt es vier Hauptmethoden, die du kennen solltest:
| Methode | Was sie tut | Restaurant-Vergleich |
|---|---|---|
| GET | Daten abrufen | "Was steht auf der Karte?" |
| POST | Neue Daten erstellen | "Ich bestelle das Schnitzel" |
| PUT | Bestehende Daten aktualisieren | "Doch lieber ohne Soße" |
| DELETE | Daten löschen | "Bestellung stornieren" |
API-Typen: REST vs. GraphQL vs. SOAP
Nicht jede API funktioniert gleich. Es gibt verschiedene Architekturstile, und die drei wichtigsten sind REST, GraphQL und SOAP.
REST API
REST steht für "Representational State Transfer" und ist der mit Abstand beliebteste API-Typ. Wenn jemand "API" sagt, meint er meistens eine REST API.
Wie funktioniert REST?
Jede Ressource (Nutzer, Artikel, Produkt) hat eine eigene URL. Du greifst mit HTTP-Methoden darauf zu.
GET /users- Alle Nutzer abrufenGET /users/42- Nutzer mit ID 42 abrufenPOST /users- Neuen Nutzer erstellenDELETE /users/42- Nutzer 42 löschen
REST ist einfach, weit verbreitet und gut dokumentiert. Deshalb nutze ich REST für die meisten Projekte.
GraphQL
GraphQL wurde von Facebook entwickelt und löst ein Problem von REST: Du bekommst immer genau die Daten, die du brauchst. Nicht mehr, nicht weniger.
Das Problem bei REST: Du fragst nach einem Nutzerprofil und bekommst 50 Felder zurück, brauchst aber nur Name und Profilbild. Das ist verschwendete Bandbreite, besonders auf mobilen Geräten.
GraphQL löst das so: Du sagst exakt, welche Felder du willst:
query {
user(id: 42) {
name
profilePicture
}
}
Und du bekommst nur das zurück. Nicht mehr, nicht weniger.
GraphQL ist mächtiger, aber auch komplexer einzurichten. Für Apps mit vielen verschiedenen Datenansichten ist es super. Für einfache CRUD-Anwendungen oft Overkill.
SOAP
SOAP (Simple Object Access Protocol) ist der Dinosaurier unter den API-Typen. Er nutzt XML statt JSON und hat strikte Standards.
SOAP findest du heute hauptsächlich in Großunternehmen, Banken und Versicherungen. Wenn du mit SAP oder anderen Enterprise-Systemen arbeitest, wirst du wahrscheinlich auf SOAP stoßen.
Für moderne App-Entwicklung ist SOAP meistens zu umständlich. Ich empfehle REST oder GraphQL.
Vergleichstabelle
| Eigenschaft | REST API | GraphQL | SOAP |
|---|---|---|---|
| Datenformat | JSON | JSON | XML |
| Flexibilität | Fest definierte Endpunkte | Client bestimmt die Daten | Strikt definiert |
| Lernkurve | Niedrig | Mittel | Hoch |
| Performance | Gut | Sehr gut (weniger Daten) | Schwerfällig |
| Verbreitung | Sehr hoch | Wachsend | Rückläufig |
| Ideal für | Die meisten Apps | Komplexe, datenintensive Apps | Enterprise & Legacy |
| Caching | Einfach | Komplex | Komplex |
REST API Beispiel aus der Praxis
Genug Theorie, jetzt wird's praktisch. So sieht ein echter API-Aufruf aus. Nehmen wir an, du willst einen Nutzer von einer API abrufen.
Mit curl (Terminal)
curl https://api.example.com/users/42 \
-H "Authorization: Bearer dein-api-key"
Mit JavaScript (fetch)
const response = await fetch('https://api.example.com/users/42', {
headers: {
'Authorization': 'Bearer dein-api-key'
}
});
const user = await response.json();
console.log(user.name); // "Max Mustermann"
Die Antwort (Response)
{
"id": 42,
"name": "Max Mustermann",
"email": "max@example.com",
"created_at": "2026-01-15T10:30:00Z"
}
Das ist im Prinzip alles. Du schickst eine Anfrage, du bekommst strukturierte Daten zurück. Dein Frontend kann diese Daten dann anzeigen. So funktioniert jede moderne App.
Warum sind APIs wichtig für App-Entwicklung?
Kurze Antwort: Ohne APIs keine modernen Apps.
1. Frontend und Backend verbinden
Dein Frontend - also die App auf dem Smartphone oder die Website im Browser - muss irgendwie mit dem Backend kommunizieren. Nutzer anmelden, Daten laden, Bestellungen aufgeben. All das passiert über APIs.
2. Externe Dienste integrieren
Du willst Zahlungen akzeptieren? Stripe-API. Push-Notifications senden? Firebase-API. Standort ermitteln? Google Maps API. E-Mails versenden? SendGrid-API.
Statt alles selbst zu bauen, nutzt du bestehende APIs. Das spart Monate an Entwicklungszeit.
3. Microservices ermöglichen
Moderne Backend-Architekturen bestehen aus vielen kleinen Services, die über APIs miteinander kommunizieren. Der User-Service redet mit dem Notification-Service, der redet mit dem Email-Service. Jeder macht eine Sache gut. Wie das in der Praxis aussieht, habe ich in meinem Artikel über meine Backend-Architektur gezeigt.
4. Plattformunabhängigkeit
Eine gut designte API kann von überall aufgerufen werden. Die gleiche API bedient deine iOS-App, deine Android-App und deine Website. Du baust das Backend einmal und kannst es von überall nutzen.
5. Skalierbarkeit
Mit APIs können verschiedene Teile deines Systems unabhängig skalieren. Wenn der User-Service mehr Last hat, skalierst du nur den hoch, nicht die ganze App.
Häufige API-Begriffe erklärt
Wenn du mit APIs arbeitest, stolperst du über Fachbegriffe. Hier die wichtigsten:
Endpoint
Ein Endpoint ist eine spezifische URL, an die du Anfragen schickst. Zum Beispiel https://api.example.com/users. Jeder Endpoint steht für eine bestimmte Ressource oder Aktion.
Request / Response
Request ist deine Anfrage an die API. Response ist die Antwort. Das wars - hin und zurück.
Authentication (Authentifizierung)
Die meisten APIs sind geschützt. Du brauchst einen Schlüssel (API Key) oder Token, um dich zu identifizieren. Wie ein VIP-Ausweis am Eingang. Ohne kommst du nicht rein.
Gängige Methoden:
- API Key: Ein einfacher Schlüssel, den du bei jedem Request mitschickst
- OAuth 2.0: Ein komplexeres System, bei dem Nutzer der App Zugriff auf ihre Daten gewähren (z.B. "Mit Google einloggen")
- JWT (JSON Web Token): Ein verschlüsselter Token, der Nutzerinformationen enthält
Rate Limiting
APIs begrenzen, wie viele Anfragen du pro Zeitraum stellen darfst. Zum Beispiel: maximal 100 Anfragen pro Minute. Das schützt den Server vor Überlastung.
Wenn du das Limit erreichst, bekommst du einen 429-Statuscode ("Too Many Requests"). Dann musst du warten, bevor du die nächste Anfrage stellen kannst.
JSON
JSON (JavaScript Object Notation) ist das Standardformat für API-Daten. Es sieht so aus:
{
"name": "Max",
"age": 30,
"hobbies": ["coding", "coffee"]
}
Lesbar für Menschen, leicht zu verarbeiten für Maschinen. Deshalb hat JSON bei den meisten APIs XML als Format abgelöst.
Statuscode
HTTP-Statuscodes sagen dir, ob deine Anfrage erfolgreich war:
- 200 - OK, alles gut
- 201 - Erstellt, neue Ressource angelegt
- 400 - Schlechte Anfrage, du hast was falsch geschickt
- 401 - Nicht autorisiert, dein API Key stimmt nicht
- 403 - Verboten, du hast keine Berechtigung
- 404 - Nicht gefunden
- 429 - Zu viele Anfragen (Rate Limit)
- 500 - Serverfehler, Problem auf der Gegenseite
APIs im Alltag
Du benutzt APIs ständig, auch wenn du es nicht merkst. Ein paar Beispiele:
- Wetter-App: Holt Wetterdaten von einer Wetter-API
- Google Maps eingebettet: Nutzt die Google Maps API
- Social Login ("Mit Google einloggen"): Nutzt die OAuth-API von Google
- Online-Banking: Deine Banking-App kommuniziert über APIs mit der Bank
- Spotify: Die App holt Playlists, Songs und Empfehlungen per API
- Online-Bestellung: Der Webshop kommuniziert über APIs mit dem Zahlungsanbieter und dem Versanddienstleister
Jedes Mal, wenn eine App Daten aus dem Internet lädt, steckt eine API dahinter.
API-Design: Was macht eine gute API aus?
Falls du selbst APIs baust, oder deinem Entwicklerteam Feedback geben willst, hier ein paar Prinzipien, auf die es ankommt:
Konsistenz
Endpunkte sollten einer logischen Struktur folgen. Wenn /users/42 einen Nutzer zurückgibt, sollte /products/42 ein Produkt zurückgeben. Gleiche Muster, gleiche Logik.
Gute Fehlermeldungen
Statt nur "Error" sollte die API sagen, was genau schiefgelaufen ist:
{
"error": "validation_failed",
"message": "Das Feld 'email' ist erforderlich",
"field": "email"
}
Versionierung
APIs ändern sich. Damit bestehende Apps nicht kaputtgehen, nutzt man Versionierung: /v1/users und /v2/users können parallel existieren.
Dokumentation
Eine API ohne Dokumentation ist wie ein Restaurant ohne Speisekarte. Niemand weiß, was es gibt. Gute Doku enthält Beispiele, Fehlercodes und Erklärungen zu jedem Endpoint.
Häufig gestellte Fragen
Nein, das Grundkonzept ist einfach: Anfrage rein, Antwort raus. Um APIs selbst zu nutzen oder zu bauen, brauchst du Programmierkenntnisse. Aber um zu verstehen, was APIs sind und wozu man sie braucht, reicht gesunder Menschenverstand. Du sprichst ja auch mit dem Kellner im Restaurant, ohne Koch sein zu müssen.
APIs können sehr sicher sein, wenn sie richtig umgesetzt werden. Verschlüsselung (HTTPS), Authentifizierung (API Keys, OAuth), Rate Limiting und Input-Validierung sind Standardpraktiken. Eine schlecht gesicherte API ist allerdings ein Sicherheitsrisiko. API-Sicherheit solltest du deshalb von Anfang an mitdenken.
Viele APIs bieten kostenlose Basispakete an. Die Google Maps API hat ein Freikontingent, die OpenWeatherMap API ist für geringe Nutzung kostenlos. Ab einer gewissen Nutzung fallen Kosten an, die von Anbieter zu Anbieter variieren. Eigene APIs zu betreiben kostet Serverressourcen, die du in den laufenden Kosten einplanen solltest.
Für die meisten Projekte ist REST die bessere Wahl. Es ist einfacher, es gibt mehr Ressourcen und Tutorials, und die meisten externen APIs sind REST. GraphQL lohnt sich, wenn du viele verschiedene Datenansichten hast und die Datenübertragung optimieren willst, zum Beispiel bei komplexen mobilen Apps. Im Zweifelsfall: Starte mit REST.
Überleg dir zuerst, welche Funktion du brauchst: Zahlungen, E-Mail-Versand, Wetterdaten? Dann such nach Anbietern. Plattformen wie RapidAPI listen tausende APIs auf. Achte auf: gute Dokumentation, zuverlässige Uptime, faire Preise und aktiven Support. Und teste die API mit Postman oder curl, bevor du sie in dein Projekt einbaust.
Ja, und das ist oft nötig. Sobald deine App ein Backend braucht, baust du automatisch eine API. Frameworks wie Express (Node.js), FastAPI (Python), Serverpod (Dart) oder NestJS machen den Einstieg einfach. Fang mit einer simplen REST API an und erweitere sie nach Bedarf.



