So funktionieren REST-APIs — der Umlauf einer Anfrage

So funktionieren REST-APIs — der Umlauf einer Anfrage

Die interaktive FlowJam-Zeichenfläche zu dieser Erklärung — jede Bahn, jede Zeile und jeder Pfeil oben gehört zu einem echten QueryChart-Diagramm, das Sie öffnen und bearbeiten können.

So lesen Sie diese Darstellung

• Lesen Sie die drei Spalten von links nach rechts: Anfrage, Verarbeitung im Server, Antwort.
• Die Client-Zeile und die Server-Zeile wechseln sich ab, deshalb ist jeder Pfeil entweder der Client, der etwas sendet, oder der Server, der etwas entscheidet.
• Die Entscheidung „Ist die Anfrage gültig?“ führt entweder auf den erfolgreichen Weg oder auf das Ende „Server liefert 400 / 401 / 403“ — die beiden Ausgänge, die jeder API-Aufruf haben kann.

Die Anfrage

„Client baut eine HTTP-Anfrage (Methode, URL, Header, Body)“ ist der Anfang jeder REST-Interaktion. Die Methode ist das Verb — GET liest, POST erzeugt, PUT ersetzt, PATCH aktualisiert, DELETE entfernt —, und die URL benennt die Ressource, also ist „/users/42“ die Anfrage, einen einzelnen Nutzer zu lesen. „Client sendet die Anfrage über HTTPS“ ist der Transport: REST setzt auf HTTP auf, und HTTPS hält das Gespräch über derselben Internet-Infrastruktur privat, die die anderen Darstellungen abbilden.

Die Arbeit des Servers

„Server leitet die URL an den passenden Handler“ bildet die Anfrage auf Code ab, und „Ist die Anfrage gültig?“ ist die Schranke: Authentifizierung (wer Sie sind), Autorisierung (ob Sie dürfen) und die Prüfung der Nutzdaten passieren hier, wobei Fehlschläge an das Ende „Server liefert 400 / 401 / 403“ gehen. „Handler führt die Geschäftslogik aus“ und „Server liest oder schreibt die Ressource in der Datenbank“ sind die eigentliche Arbeit — der Teil, den der Client nie sieht.

Die Antwort

„Server baut die Antwort mit Statuscode und JSON-Body“ ist der Vertrag in maschinenlesbarer Form: 200 für Erfolg, 201 für angelegt, 404 für nicht vorhanden, 500 für einen Serverfehler. „Client empfängt die Antwort und liest sie aus“ und „Client zeigt dem Nutzer das Ergebnis“ schließen den Kreis — der Umlauf endet dort, wo er begonnen hat, im Client, und genau deshalb kehrt die Darstellung in die Client-Zeile zurück.

Wichtige Zusammenhänge und Erkenntnisse

• REST ist ein Vertrag in HTTP: Methoden sind Verben, URLs sind Ressourcen, und Statuscodes sind das maschinenlesbare Ergebnis.
• Der Client ist zustandslos — jede Anfrage trägt alles, was der Server braucht, eine gemeinsame Sitzung ist nicht nötig.
• Die Prüfung ist die Sicherheitsgrenze; eine ungültige Anfrage wird abgewiesen, bevor Geschäftslogik läuft.
• Die Antwort ist zuerst über ihren Statuscode definiert und erst danach über ihren Body.
• REST-Verkehr läuft über dieselbe DNS-, HTTPS- und Internet-Infrastruktur, die die anderen Technik-Darstellungen abbilden.

Wann Sie diese Darstellung nutzen

• Das Modell aus HTTP-Methode, URL und Statuscode vermitteln, bevor ein Team seinen ersten Endpunkt entwirft.
• Den Vertrag einer API prüfen — sind Fehler Statuscodes oder 200 mit einem Flag? — und ihn an der REST-Konvention messen.
• Ein Gespräch über Idempotenz und Caching daran verankern, wie Anfragen tatsächlich gebaut und geprüft werden.

So funktioniert es

1. Bilden Sie Ihre eigenen Endpunkte am Anfragekasten ab

   Ergänzen Sie Notizen mit Ihren echten Methoden und Routen — GET /orders, POST /payments —, damit das Diagramm die Oberfläche Ihrer API dokumentiert.

2. Benennen Sie Ihre Statuscodes

   Vermerken Sie am Antwortschritt die Codes, die Ihre API für jeden Ausgang tatsächlich liefert, und ergänzen Sie die, die Ihr Vertrag über 200 und 400 hinaus nutzt.

3. Ergänzen Sie die Authentifizierung

   Fügen Sie zwischen Client und Prüfschranke den Token-Schritt ein — ein JWT oder ein OAuth-Token im Authorization-Header —, um zu zeigen, wo die Identität in die Anfrage kommt.

4. Zeichnen Sie die Zweige für Wiederholung und Fehler

   Ergänzen Sie ausdrückliche Enden für Netzwerkfehler, Rate Limiting und Serverfehler, jeweils mit dem Verhalten des Clients (Wiederholung, Backoff, Fehlerzustand), das sie auslösen.

Häufig gestellte Fragen

Was ist eine REST-API?

Eine REST-API ist eine Menge von HTTP-Endpunkten, die die Ressourcen eines Systems zugänglich machen. Clients wirken mit HTTP-Methoden auf Ressourcen ein — GET zum Lesen, POST zum Anlegen, PUT oder PATCH zum Ändern, DELETE zum Entfernen — und der Server antwortet mit einem Statuscode und einer Darstellung der Ressource, meist JSON. REST ist ein Stil und kein Standard, und sein Wert liegt darin, dass jeder Client, der HTTP spricht, ihn nutzen kann.

Was unterscheidet GET, POST, PUT und DELETE?

Sie sind die Verben des REST-Vertrags. GET liest eine Ressource und sollte keine Nebenwirkungen haben. POST legt eine neue Ressource an und gibt deren Identität zurück. PUT ersetzt eine Ressource vollständig und ist idempotent — eine Wiederholung ändert nichts weiter. PATCH führt eine teilweise Änderung durch. DELETE entfernt eine Ressource. Zusammen benennen Verb und URL die vollständige Aktion, und deshalb nennt der Anfragekasten in der Darstellung die Methode zuerst.

Warum sind Statuscodes in REST wichtig?

Weil sie das maschinenlesbare Ergebnis der Anfrage sind. Ein Client kann anhand des Statuscodes verzweigen, ohne den Body zu lesen: 2xx Erfolg, 4xx Fehler des Clients, 5xx Fehler des Servers. APIs, die 200 mit einem Fehler-Flag im Body liefern, brechen diesen Vertrag und zwingen jeden Client zu einer Sonderbehandlung der Antwort.

Was macht eine API „RESTful“?

Die praktische Prüfliste: Ressourcen über URLs benannt, Aktionen als HTTP-Methoden ausgedrückt, zustandslose Anfragen (jede trägt alles, was der Server braucht), Antworten, die Statuscodes richtig nutzen, und oft Hypermedia oder versionierte URLs. Die Zeichenfläche bildet den Umlauf ab — Anfrage, Prüfung, Verarbeitung, Antwort —, und diese Form teilt jeder RESTful-Austausch.

Diese Darstellung in QueryChart (FlowJam) bearbeiten

Öffnen Sie genau diese REST-Zeichenfläche als eigenes Diagramm, benennen Sie Client und Server auf Ihre Services um und vermerken Sie Ihre Endpunkte.

Diese Darstellung in QueryChart (FlowJam) bearbeiten