Sofortantwort
REST einfach erklärt
Architekturstil für Web-APIs basierend auf HTTP-Methoden.
- Kurz gesagt
- Ressourcen-orientiert: Jede Entität hat eine eindeutige URL
- Typischer Einsatz
- KI-APIs, Web-Anwendungen, Mobile Apps
- Wichtig zu wissen
- Zustandslos: Jede Anfrage enthält alle nötigen Informationen
REST im Überblick
REST (Representational State Transfer) ist das Architekturmuster, das das Web antreibt. Es definiert, wie Client und Server über HTTP kommunizieren – mit klaren Konventionen für URLs (Ressourcen), HTTP-Methoden (GET lesen, POST erstellen, PUT aktualisieren, DELETE löschen) und Statuscodes. Für KI-Systeme ist REST der Standard, um Modelle als API bereitzustellen: Ein POST-Request mit dem Input, ein JSON-Response mit der Vorhersage. Alle großen KI-APIs – OpenAI, Anthropic, Google – folgen REST-Konventionen.
REST (Representational State Transfer) ist das dominante Architekturmuster für Web-APIs. Es definiert, wie Client und Server über HTTP kommunizieren – mit klaren Konventionen für URLs, HTTP-Methoden (GET, POST, PUT, DELETE) und Statuscodes. Für KI-Systeme ist REST der Standard, um Modelle als API bereitzustellen: Ein POST-Request mit dem Input, ein JSON-Response mit der Vorhersage.
REST ist ein Architekturstil, der definiert, wie Web-APIs aufgebaut sein sollten. Fast alle KI-APIs (OpenAI, Anthropic, Google) nutzen REST.
Beispiel – OpenAI Chat API:
POST https://api.openai.com/v1/chat/completions
Headers: Authorization: Bearer sk-...
Body: {"model": "gpt-5", "messages": [{"role": "user", "content": "Hallo!"}]}
Response: {"choices": [{"message": {"content": "Hallo! Wie kann ich helfen?"}}]}
REST-Prinzipien:
| Prinzip | Beschreibung |
|---|---|
| Zustandslos | Jede Anfrage ist unabhängig, kein Session-State auf dem Server |
| Ressourcen-basiert | Alles ist eine Ressource mit eigener URL |
| Einheitliche Schnittstelle | Standardisierte HTTP-Methoden und Statuscodes |
| Client-Server | Klare Trennung zwischen Frontend und Backend |
Technisch betrachtet
HTTP-Statuscodes
- 200 OK: Erfolgreiche Anfrage
- 201 Created: Ressource erfolgreich erstellt
- 400 Bad Request: Fehlerhafte Anfrage
- 401 Unauthorized: Nicht authentifiziert
- 404 Not Found: Ressource nicht gefunden
- 429 Too Many Requests: Rate Limit erreicht
- 500 Internal Server Error: Serverfehler
REST API Design
GET /api/v1/models → Liste aller Modelle
GET /api/v1/models/gpt-5 → Details eines Modells
POST /api/v1/chat/completions → Chat-Anfrage senden
DELETE /api/v1/files/file-123 → Datei löschen
Pagination, Filtering, Sorting
- Pagination:
?page=2&limit=20oder Cursor-basiert - Filtering:
?status=active&category=llm - Sorting:
?sort=created_at&order=desc
Schritt für Schritt
Eine REST-API von der Aufgabe zum Vertrag entwickeln
Gute REST-Schnittstellen beginnen bei den Bedürfnissen der Clients und machen Verhalten, Grenzen und Fehlerfälle explizit.
Ressourcen und Aufgaben beschreiben
01
Benennen, welche fachlichen Objekte die API bereitstellt und welche Handlungen darauf erlaubt sind.
Ressource | lesen | erstellen | ändern | löschenKlare Endpunkte und Datenformate definieren
02
URLs, Methoden, Eingabe- und Antwortformate werden konsistent und unabhängig von einer einzelnen Oberfläche gestaltet.
GET /resources/{id} → 200 + RepräsentationFehler und Grenzfälle festlegen
03
Clients brauchen verständliche Antworten bei ungültigen Eingaben, fehlenden Rechten, Konflikten oder Rate Limits.
Statuscode + Fehlercode + sichere, hilfreiche NachrichtZugriff und Zuverlässigkeit absichern
04
Autorisierung, Eingabeprüfung, Zeitlimits und idempotente Abläufe schützen API und Nutzer.
Anfrage → Auth → Validierung → Fachlogik → AntwortVertrag dokumentieren und versionieren
05
Eine maschinenlesbare Spezifikation, Beispiele und Änderungen halten Client und Server synchron.
OpenAPI → Tests → SDKs → Änderungslog
Konkretes Beispiel
Beispiel: API für ein Wissensportal
Ein Frontend zeigt Artikel, verwandte Begriffe und gespeicherte Leselisten.
Client-Bedarf
Die Oberfläche braucht eine stabile Möglichkeit, Begriffe zu laden und eine Leseliste zu aktualisieren – auch bei wiederholten Anfragen.
Schnittstellenvertrag
Klare Ressourcen-Endpunkte, dokumentierte Datenformate, nachvollziehbare Fehlerantworten und ein abgesicherter Schreibvorgang für die Leseliste.
Eine gute API beschreibt nicht nur den Erfolgsfall, sondern macht auch Grenzen und erwartbares Verhalten für alle Clients klar.
Einordnung
Vorteile und Grenzen
Das spricht dafür
- Breit verständlich: HTTP-Methoden und Ressourcenmuster sind für viele Teams und Werkzeuge vertraut.
- Gut entkoppelbar: Unterschiedliche Clients können denselben stabilen Vertrag nutzen.
- Einfach beobachtbar: Endpunkte, Statuscodes und Zugriffe lassen sich gut dokumentieren und überwachen.
Das solltest du beachten
- Mehrere Abrufe möglich: Komplexe Oberflächen brauchen manchmal viele Endpunkte oder Runden.
- Designarbeit nötig: Inkonsistente Ressourcen und Statuscodes machen eine API langfristig schwer nutzbar.
- Versionen bleiben Herausforderung: Änderungen müssen alte Clients angemessen berücksichtigen.
Vertiefung · für FortgeschritteneDie Schichten einer REST-Anfrage
Eine Anfrage durchläuft klar getrennte Schritte, bevor sie zu einer nutzbaren Antwort wird.
Methode und URL beschreiben die gewünschte Operation auf einer Ressource.