Eine REST API ist die Sprache, in der sich Programme im Web unterhalten – und wenn du sie einmal verstanden hast, fügt sich plötzlich das halbe Internet zu einem klaren Bild zusammen. In diesem Guide erklären wir dir REST mit einer Restaurant-Analogie, die hängen bleibt, zeigen dir die HTTP-Methoden als Tabelle und gehen ein echtes JSON-Beispiel Zeile für Zeile durch. Danach weißt du, was eine API macht, wie eine Anfrage aussieht und woran du eine richtig gute API erkennst.

Was ist eine API – und was bedeutet REST?

API steht für Application Programming Interface, auf Deutsch „Programmier-Schnittstelle“. Sie ist die definierte Tür, durch die ein Programm bei einem anderen etwas bestellen kann. Deine Wetter-App hat selbst keine Wetterdaten – sie fragt über eine API einen Wetterdienst und bekommt die Daten zurück. Du musst dafür nicht wissen, wie der Wetterdienst intern rechnet. Du nutzt nur seine Schnittstelle.

REST (Representational State Transfer) ist ein bestimmter Architekturstil für solche Web-Schnittstellen. Eine REST API baut konsequent auf den Mechanismen auf, die das Web sowieso schon nutzt: Adressen (URLs), HTTP-Methoden und Statuscodes. Genau das macht REST so beliebt – es braucht keine exotische Technik, sondern nutzt das HTTP-Protokoll, das jeder Browser ohnehin spricht.

Die Restaurant-Analogie

Stell dir ein Restaurant vor. Du sitzt am Tisch (das ist deine App). Die Küche kocht (das ist der Server mit der Datenbank). Dazwischen läuft der Kellner – das ist die REST API.

HTTP-Methoden: GET, POST, PUT, DELETE

Jede Anfrage an eine REST API benutzt eine HTTP-Methode (auch „Verb“ genannt). Sie sagt dem Server, was du mit einer Ressource vorhast. Du kommst im Alltag mit vier Methoden extrem weit:

Endpoints & Ressourcen: die Adressen der Daten

In REST dreht sich alles um Ressourcen – also Dinge, mit denen du arbeitest: Kunden, Produkte, Bestellungen, Artikel. Jede Ressource bekommt eine eindeutige Adresse, den Endpoint. Eine gute Faustregel: Ressourcen sind Substantive im Plural, einzelne Einträge bekommen eine ID dahinter.

• /produkte → alle Produkte (eine Sammlung)
• /produkte/7 → das eine Produkt mit der ID 7
• /produkte/7/bewertungen → die Bewertungen zu diesem Produkt

Wichtig: Derselbe Endpoint verhält sich je nach Methode anders. GET /produkte liefert die Liste, POST /produkte legt ein neues Produkt an. Adresse und Verb ergeben zusammen erst die komplette Aktion. Zusätzliche Filter hängst du als Query-Parameter an, etwa GET /produkte?kategorie=schuhe&limit=20.

Statuscodes: Hat es geklappt?

Auf jede Anfrage antwortet der Server mit einem dreistelligen HTTP-Statuscode. Schon die erste Ziffer verrät die Stimmung: 2xx heißt Erfolg, 4xx heißt „Du hast einen Fehler gemacht“, 5xx heißt „Der Server hat einen Fehler“.

Ein echtes Beispiel: Request und Response in JSON

Schauen wir uns an, wie es konkret aussieht, wenn du einen neuen Kunden anlegst. Du schickst per POST die Daten als JSON (JavaScript Object Notation) – ein schlankes Textformat aus Schlüssel-Wert-Paaren, das Menschen und Maschinen gleichermaßen lesen können.

POST /kunden  HTTP/1.1
Host: api.beispielshop.de
Content-Type: application/json

{
  "name": "Lena Vogt",
  "email": "[email protected]",
  "newsletter": true
}

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": 42,
  "name": "Lena Vogt",
  "email": "[email protected]",
  "newsletter": true,
  "erstellt_am": "2026-06-19T10:24:00Z"
}

Was ist passiert? Du hast Name und E-Mail geschickt. Der Server hat den Datensatz gespeichert, ihm eine eindeutige id vergeben und einen Zeitstempel ergänzt. Der Statuscode 201 Created bestätigt: angelegt. Ab jetzt kannst du diesen Kunden über GET /kunden/42 jederzeit wieder abrufen oder mit PUT /kunden/42 aktualisieren. Genau dieser saubere, vorhersehbare Ablauf macht REST in der Praxis so angenehm.

Was macht eine gute REST API aus?

Technisch funktionsfähig ist schnell – richtig gut ist eine API erst, wenn andere Entwickler sie ohne Frust benutzen können. Daran erkennst du Qualität:

• Klare, konsistente Endpoints: Immer Plural-Substantive, vorhersehbare Muster. Wer /kunden kennt, errät /bestellungen richtig.
• Korrekte Statuscodes: Erfolg ist 2xx, Client-Fehler 4xx, Server-Fehler 5xx – nicht alles pauschal mit 200 beantworten.
• Aussagekräftige Fehlermeldungen: Nicht nur „Fehler“, sondern was falsch war, etwa „E-Mail-Format ungültig“.
• Versionierung: z. B. /v1/kunden, damit Änderungen bestehende Apps nicht über Nacht zerstören.
• Sicherheit: Zugriff über HTTPS und Authentifizierung (z. B. API-Schlüssel oder Token).
• Gute Doku & Stateless: Eine verständliche Anleitung und der Grundsatz, dass jede Anfrage für sich vollständig ist – der Server merkt sich zwischen zwei Aufrufen nichts.

Häufige Fragen