RESTful Design-Prinzipien

Dieser Beitrag ist eine Begriffserklärung zu RESTful Design-Prinzipien – inklusive Prüfungsfragen und Tags.

In a Nutshell

REST ist ein Architekturansatz für APIs, der auf HTTP basiert und durch klar definierte Methoden, Ressourcen, Statuscodes und Zustandslosigkeit besticht.

Kompakte Fachbeschreibung

REST ist ein leichtgewichtiges, auf HTTP basierendes Protokoll für den Austausch von Ressourcen zwischen Client und Server. Es nutzt die HTTP-Methoden: GET (Lesen), POST (Erstellen), PUT (Ersetzen), DELETE (Löschen), PATCH (Teilaktualisierung). REST folgt dem Prinzip der Statelessness, was bedeutet, dass jeder Request alle nötigen Informationen enthalten muss, der Server speichert keine Sitzungsdaten. Idempotenz spielt eine wichtige Rolle: GET, PUT und DELETE sind idempotent (mehrfache Ausführung hat dieselbe Wirkung), POST und PATCH sind es nicht. REST verwendet standardisierte Statuscodes (z.B. 200 OK, 201 Created, 404 Not Found, 500 Server Error) zur Kommunikation von Ergebnissen.

Prüfungsrelevante Stichpunkte

• GET, POST, PUT, DELETE, PATCH: HTTP-Methoden für CRUD
• REST ist zustandslos – kein Session-Tracking auf Serverseite
• Idempotenz: Wiederholte Requests wirken nur einmal (z.B. bei PUT)
• Ressourcenorientierte URIs, z.B. /api/users/123
• Nutzung von HTTP-Statuscodes (200, 201, 404, 500 etc.)
• PATCH aktualisiert nur Teile eines Objekts
• Sicherheitsaspekte: Authentifizierung per Token, HTTPS, CORS
• Dokumentation der Schnittstellen mit OpenAPI oder Swagger

Kernkomponenten

1. HTTP-Methoden (GET, POST, PUT, DELETE, PATCH)
2. URI-Konventionen (ressourcenbasiert)
3. Statuscodes (2xx, 4xx, 5xx)
4. REST-Konformität (Richardson Maturity Model)
5. Idempotenz-Regeln
6. Stateless-Architektur
7. Content Negotiation (Accept-/Content-Type-Header)
8. JSON/XML als Datenformate
9. Authentifizierung (Bearer Token, API Keys)
10. OpenAPI/Swagger-Dokumentation

Praxisbeispiel

// Beispiel: REST-API zur Benutzerverwaltung
GET /users → Liste aller Nutzer
POST /users → Neuen Nutzer erstellen
GET /users/1 → Nutzer mit ID 1 anzeigen
PUT /users/1 → Nutzer vollständig ersetzen
PATCH /users/1 → Nur bestimmte Felder aktualisieren
DELETE /users/1 → Nutzer löschen

Erklärung: Jede Methode entspricht einer klar definierten Aktion auf einer Ressource. Die URI bleibt konstant, die Methode ändert die Semantik.

Vorteile und Nachteile

Vorteile

• Einfach, leicht verständlich
• Nutzt Standardprotokolle (HTTP)
• Plattform- und sprachunabhängig
• Gut skalierbar

Nachteile

• Kein eingebautes Session-Management
• Kann ineffizient bei vielen API-Aufrufen sein
• Keine Standardisierung für komplexe Operationen

Typische Prüfungsfragen (mit Kurzantwort)

1. “Stateless” bei REST? Server speichert keine Sitzungsdaten – jeder Request muss vollständig sein.
2. Idempotente HTTP-Methoden? GET, PUT, DELETE.
3. Unterschied PUT vs. PATCH? PUT ersetzt ein Objekt vollständig, PATCH ändert nur bestimmte Felder.
4. Statuscode 201? Ressource erfolgreich erstellt.
5. REST vs. SOAP? REST ist leichtgewichtig, nutzt HTTP direkt, SOAP ist XML-basiert und schwergewichtig.
6. Ressource adressieren? Durch URI, z.B. /users/123.
7. Sicherheitsmaßnahmen bei REST-APIs? HTTPS, Token-Authentifizierung, Zugriffskontrolle.
8. Warum Idempotenz wichtig? Wiederholungen bei Netzwerkausfällen haben keine unbeabsichtigten Folgen.

Wichtigste Quellen

1. https://learn.microsoft.com/en-us/azure/architecture/best-practices/api-design
2. https://developer.mozilla.org/de/docs/Web/HTTP/Methods
3. https://restfulapi.net/
4. https://swagger.io/specification/
5. https://www.howtographql.com/basics/1-graphql-vs-rest/