REST (Representational State Transfer) ist ein Architekturstil für vernetzte Anwendungen, definiert von Roy Fielding. Es ist kein Protokoll oder Standard — es ist eine Menge von Constraints, die eine API, wenn man sie befolgt, skalierbar, cachebar und leicht weiterzuentwickeln machen. Eine "RESTful" API modelliert alles als Ressourcen (User, Orders, Products), identifiziert durch URIs, und manipuliert sie mit Standard-HTTP-Methoden.
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 42, "name": "Ann", "email": "[email protected]" }
Der URI /users/42 benennt die Ressource; GET ist die Aktion; JSON ist die Repräsentation. Diese Kombination — Substantive im Pfad, Verben als HTTP-Methoden — ist der Kern von REST.
REST ist der dominante Stil für Web-APIs, daher nutzen Interviewer diese Frage, um zu prüfen, ob du verstehst, warum es funktioniert, nicht nur, dass du es buchstabieren kannst. Die zwei in der Praxis wichtigsten Constraints sind Statelessness (jeder Request ist in sich geschlossen, sodass du beliebig viele Server hinter einen Load Balancer stellen und horizontal ohne Sticky Sessions skalieren kannst) und das Uniform Interface (vorhersehbare, ressourcenorientierte URLs plus Standard-HTTP-Methoden und Statuscodes, was bedeutet, dass Clients keine eigene Logik pro Endpoint brauchen). Eine starke Antwort verbindet die Constraints mit konkreten Vorteilen — Statelessness ermöglicht Skalierung, Cachebarkeit reduziert die Last, das Layered System erlaubt das Einfügen von CDNs und Gateways — und merkt an, dass die meisten "REST"-APIs pragmatisch statt vollständig RESTful sind (wenige implementieren HATEOAS). Diese Constraints zu verstehen ist die Grundlage für jede andere REST-Design-Entscheidung, vom Wählen der Statuscodes bis zum Versioning.
Eine Sammlung von IT-Interviewfragen mit ausführlichen Antworten — vom Junior bis zum Senior.
Spenden