REST (Representational State Transfer)

Wie Teams Ressourcen, Schnittstellenverträge und Fehlerfälle so gestalten, dass APIs langfristig verständlich bleiben.

Ein Architekturstil für Web-APIs, der auf HTTP-Methoden und Ressourcen basiert – der De-facto-Standard für die meisten Web-Schnittstellen und KI-APIs.

Einsteiger2 Min Lesezeit

Erklärung starten

Auf einen Blick

3 Punkte

  1. Ressourcen-orientiert: Jede Entität hat eine eindeutige URL
  2. Nutzt HTTP-Methoden (GET, POST, PUT, DELETE) für Operationen
  3. Zustandslos: Jede Anfrage enthält alle nötigen Informationen

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:

PrinzipBeschreibung
ZustandslosJede Anfrage ist unabhängig, kein Session-State auf dem Server
Ressourcen-basiertAlles ist eine Ressource mit eigener URL
Einheitliche SchnittstelleStandardisierte HTTP-Methoden und Statuscodes
Client-ServerKlare 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=20 oder 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.

  1. Ressourcen und Aufgaben beschreiben

    01

    Benennen, welche fachlichen Objekte die API bereitstellt und welche Handlungen darauf erlaubt sind.

    Ressource | lesen | erstellen | ändern | löschen
  2. Klare 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äsentation
  3. Fehler und Grenzfälle festlegen

    03

    Clients brauchen verständliche Antworten bei ungültigen Eingaben, fehlenden Rechten, Konflikten oder Rate Limits.

    Statuscode + Fehlercode + sichere, hilfreiche Nachricht
  4. Zugriff und Zuverlässigkeit absichern

    04

    Autorisierung, Eingabeprüfung, Zeitlimits und idempotente Abläufe schützen API und Nutzer.

    Anfrage → Auth → Validierung → Fachlogik → Antwort
  5. Vertrag 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 Fortgeschrittene

Die Schichten einer REST-Anfrage

Eine Anfrage durchläuft klar getrennte Schritte, bevor sie zu einer nutzbaren Antwort wird.

Wissenskarte

Methode und URL beschreiben die gewünschte Operation auf einer Ressource.

Ein klarer Vertrag verbindet Client-Erwartungen mit sicheren und beobachtbaren Serverabläufen. HTTP-Anfrage gliedert sich in: Authentifizierung, Autorisierung, Validierung, Fachlogik, Datenspeicher, Antwort.

01Einsatzbereiche

Wann ist REST sinnvoll?

Geeignet für

  • KI-APIsOpenAI, Anthropic und Google AI nutzen REST APIs für ihre Modelle
  • Web-AnwendungenFrontend-Backend-Kommunikation in Single Page Applications
  • Mobile AppsDatenaustausch zwischen App und Server
  • MicroservicesKommunikation zwischen einzelnen Services

↑ Inhalt

02Werkzeuge

Womit REST umgesetzt wird

↑ Inhalt

Merksatz

REST ist wie ein Bibliothekssystem

Jedes Buch (Ressource) hat eine eindeutige Signatur (URL), und du kannst es ausleihen (GET), zurückgeben (DELETE), ein neues hinzufügen (POST) oder den Titel ändern (PUT).

  1. Ressourcen-orientiert: Jede Entität hat eine eindeutige URL
  2. Nutzt HTTP-Methoden (GET, POST, PUT, DELETE) für Operationen
  3. Zustandslos: Jede Anfrage enthält alle nötigen Informationen

03Wissensnetz

Diese Begriffe brauchst du ebenfalls

Nicht „ähnliche Artikel", sondern die Rolle, die jeder Begriff für REST spielt.

↑ Inhalt

04Anwenden

REST praktisch anwenden

  • REST vs. GraphQL

    Einfachheit und Caching oder flexible Abfragen?

    Vergleich · 8 Kriterien · 3 Min

↑ Inhalt

05Direkt anwenden

Mit diesem Prompt weiterarbeiten

Eine fertige Vorlage, die REST in eine konkrete Aufgabe übersetzt.
CodeExperte

REST-API designen

RESTful API-Design mit Endpunkten, Datenmodellen und Fehlerbehandlung.

3 Variablen · 4 Min

↑ Inhalt

06Redaktion

Herkunft und Stand

Redaktion und Aktualität

Ebenex RedaktionRedaktion

Veröffentlicht
Aktualisiert

Dieses Feld entwickelt sich schnell. Oben stehen Veröffentlichung und letzte Änderung; ein Prüfdatum kommt dazu, sobald die Erklärung nach ihrer letzten Änderung geprüft wurde.

↑ Inhalt

07FAQ

Häufige Fragen zu REST

Was bedeutet 'RESTful'?

Eine API ist 'RESTful', wenn sie die REST-Prinzipien befolgt: Zustandslosigkeit, einheitliche Schnittstelle, Ressourcen-Orientierung und Client-Server-Trennung. In der Praxis halten sich nicht alle 'REST APIs' streng an alle Prinzipien.

REST oder GraphQL?

REST ist einfacher und der Standard für die meisten APIs. GraphQL ist besser, wenn Clients flexible Datenabfragen brauchen oder Over-/Under-Fetching ein Problem ist. Für KI-APIs ist REST der klare Standard.

Wie implementiere ich eine REST-API in meiner Anwendung?

Um eine REST-API zu implementieren, solltest du zunächst die Ressourcen definieren, die deine API bereitstellen soll. Wähle dann die entsprechenden HTTP-Methoden (GET, POST, PUT, DELETE) und erstellst du Endpunkte, die diese Methoden unterstützen. Nutze Frameworks wie Express.js oder Flask, um den Prozess zu erleichtern.

Was sind die häufigsten Fehler bei der Entwicklung von REST-APIs?

Häufige Fehler bei der Entwicklung von REST-APIs sind inkonsistente URL-Strukturen, unzureichende Fehlerbehandlung und das Ignorieren von HTTP-Statuscodes. Stelle sicher, dass deine API klar dokumentiert ist und die richtigen Statuscodes zurückgibt, um den Nutzern ein besseres Verständnis der API-Antworten zu ermöglichen.

↑ Inhalt

08Weiterlernen

Was möchtest du als Nächstes verstehen?

↑ Inhalt