---
title: "Was ist eine API? Programmierschnittstellen einfach erklärt"
description: "Was ist eine API? Ich erkläre Programmierschnittstellen verständlich mit Praxis-Beispielen. REST, GraphQL und warum APIs für deine App wichtig sind."
canonical_url: "https://robocitrus.com/blog/was-ist-eine-api"
last_updated: "2026-07-19T00:11:58.128Z"
---

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?

<youtube id="eaj7ja2V3Js" title="Was ist eine API? Einfach erklärt!" upload-date="2025-03-10T12:00:00Z">



</youtube>

---

## 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](/blog/frontend-vs-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](/blog/so-funktioniert-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:

<table>
<thead>
  <tr>
    <th>
      Methode
    </th>
    
    <th>
      Was sie tut
    </th>
    
    <th>
      Restaurant-Vergleich
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        GET
      </strong>
    </td>
    
    <td>
      Daten abrufen
    </td>
    
    <td>
      "Was steht auf der Karte?"
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        POST
      </strong>
    </td>
    
    <td>
      Neue Daten erstellen
    </td>
    
    <td>
      "Ich bestelle das Schnitzel"
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        PUT
      </strong>
    </td>
    
    <td>
      Bestehende Daten aktualisieren
    </td>
    
    <td>
      "Doch lieber ohne Soße"
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        DELETE
      </strong>
    </td>
    
    <td>
      Daten löschen
    </td>
    
    <td>
      "Bestellung stornieren"
    </td>
  </tr>
</tbody>
</table>

## 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 abrufen
- `GET /users/42` - Nutzer mit ID 42 abrufen
- `POST /users` - Neuen Nutzer erstellen
- `DELETE /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:

```graphql
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

<table>
<thead>
  <tr>
    <th>
      Eigenschaft
    </th>
    
    <th>
      REST API
    </th>
    
    <th>
      GraphQL
    </th>
    
    <th>
      SOAP
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        Datenformat
      </strong>
    </td>
    
    <td>
      JSON
    </td>
    
    <td>
      JSON
    </td>
    
    <td>
      XML
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Flexibilität
      </strong>
    </td>
    
    <td>
      Fest definierte Endpunkte
    </td>
    
    <td>
      Client bestimmt die Daten
    </td>
    
    <td>
      Strikt definiert
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Lernkurve
      </strong>
    </td>
    
    <td>
      Niedrig
    </td>
    
    <td>
      Mittel
    </td>
    
    <td>
      Hoch
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Performance
      </strong>
    </td>
    
    <td>
      Gut
    </td>
    
    <td>
      Sehr gut (weniger Daten)
    </td>
    
    <td>
      Schwerfällig
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Verbreitung
      </strong>
    </td>
    
    <td>
      Sehr hoch
    </td>
    
    <td>
      Wachsend
    </td>
    
    <td>
      Rückläufig
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Ideal für
      </strong>
    </td>
    
    <td>
      Die meisten Apps
    </td>
    
    <td>
      Komplexe, datenintensive Apps
    </td>
    
    <td>
      Enterprise & Legacy
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Caching
      </strong>
    </td>
    
    <td>
      Einfach
    </td>
    
    <td>
      Komplex
    </td>
    
    <td>
      Komplex
    </td>
  </tr>
</tbody>
</table>

## 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)

```bash
curl https://api.example.com/users/42 \
  -H "Authorization: Bearer dein-api-key"
```

### Mit JavaScript (fetch)

```javascript
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)

```json
{
  "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](/blog/frontend-vs-backend) - 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](/blog/so-funktioniert-das-backend-meiner-production-app) 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:

```json
{
  "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:

```json
{
  "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

<accordion>
<accordion-item icon="i-lucide-circle-help" label="Muss ich programmieren können, um APIs zu verstehen?">

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.

</accordion-item>

<accordion-item icon="i-lucide-circle-help" label="Sind APIs sicher?">

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.

</accordion-item>

<accordion-item icon="i-lucide-circle-help" label="Was kostet es, eine API zu nutzen?">

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](/blog/laufende-app-kosten) einplanen solltest.

</accordion-item>

<accordion-item icon="i-lucide-circle-help" label="REST oder GraphQL - was soll ich nutzen?">

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.

</accordion-item>

<accordion-item icon="i-lucide-circle-help" label="Wie finde ich die richtige API für mein Projekt?">

Ü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.

</accordion-item>

<accordion-item icon="i-lucide-circle-help" label="Kann ich meine eigene API bauen?">

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.

</accordion-item>
</accordion>
