REST-API – was bedeutet eigentlich 'zustandslos', und warum ist das so wichtig?

Hallo Markus, das Prinzip klickt bei den meisten erst, wenn man sich den Gegenentwurf anschaut, also die klassische Session-basierte Anmeldung.

Stell dir vor, du loggst dich auf einer Webseite ein. Bei einer zustandsbehafteten Lösung merkt sich der Server: "Aha, dieser Nutzer ist jetzt eingeloggt" und legt dafür eine Session im Arbeitsspeicher an. Jede weitere Anfrage von dir wird dann diesem gespeicherten Zustand zugeordnet, meist über eine Session-ID im Cookie.

Bei REST läuft das anders: Beim Login schickst du deine Zugangsdaten, der Server prüft sie und gibt dir ein Token zurück (z. B. ein JWT). Dieses Token schickst du ab jetzt bei jeder Anfrage im Header mit. Der Server muss sich also nichts merken, sondern prüft bei jeder einzelnen Anfrage erneut anhand des Tokens, wer du bist und ob du berechtigt bist. Der Zustand "eingeloggt" steckt quasi im Token selbst, nicht im Server.

Der Vorteil zeigt sich bei Skalierung: Wenn du mehrere Server hinter einem Load Balancer hast, ist es egal, welcher Server deine Anfrage bearbeitet, weil keiner von ihnen einen internen Zustand über dich vorhalten muss. Bei Session-basierten Systemen müsste entweder immer derselbe Server dich bedienen (Sticky Sessions) oder die Session-Infos müssten zwischen allen Servern synchron gehalten werden, was zusätzlichen Aufwand und Fehleranfälligkeit bedeutet.

Merksatz: Zustandslosigkeit heißt nicht "der Client speichert nichts", sondern "der Server merkt sich nichts zwischen zwei Anfragen". Der Preis dafür ist tatsächlich etwas mehr Datenverkehr pro Request, aber der Gewinn an Ausfallsicherheit und horizontaler Skalierbarkeit überwiegt in der Praxis deutlich.

Danke Daniel, super erklärt. Ich ergänz mal aus der Praxis-Perspektive, weil das Thema Skalierbarkeit oft zu theoretisch bleibt.

Der Vorteil zeigt sich vor allem, wenn ein Server ausfällt oder neu gestartet wird (z. B. bei Deployments). Bei Sticky Sessions verlieren alle Nutzer, die gerade auf diesem Server "hängen", ihre Session und müssen sich neu einloggen. Bei zustandslosen APIs merkt der Nutzer davon idealerweise gar nichts, weil die nächste Anfrage einfach von einem anderen Server im Cluster übernommen wird, ohne dass Session-Daten synchronisiert werden müssten.

Das macht auch Auto-Scaling in der Cloud viel einfacher: Server hochfahren, wenn Last steigt, wieder runterfahren, wenn sie sinkt, ohne sich Gedanken über Session-Replikation zu machen.

Nachteile in der Praxis:

• Jedes Token muss bei jeder Anfrage validiert werden, das kostet etwas Rechenzeit (meistens vernachlässigbar bei JWT, weil die Signatur lokal geprüft wird).
• Ein Token-Widerruf (z. B. bei Logout oder gesperrtem Account) ist tricky, weil der Server sich ja nichts merkt. Da braucht man dann meist eine Blacklist oder kurze Ablaufzeiten, was das "reine" Zustandslosigkeitsprinzip in der Praxis leicht aufweicht.

Für die Klausur würde ich mir merken: Zustandslosigkeit ist kein Selbstzweck, sondern eine bewusste Design-Entscheidung mit Trade-offs zwischen Einfachheit/Skalierbarkeit und etwas Zusatzaufwand pro Request.