REST Architekturstil
Dieser Beitrag ist eine Begriffserklärung zu REST – inklusive Prüfungsfragen und Tags.
In a Nutshell
REST ist ein Architekturstil für verteilte Hypermedia Systeme auf Basis von HTTP. Kerngedanke: Ressourcen werden über URIs adressiert, mit standardisierten Methoden manipuliert und über Repräsentationen übertragen.
Kompakte Fachbeschreibung
REST definiert sechs Constraints: Client-Server, Zustandslosigkeit, Cache-Fähigkeit, Einheitliche Schnittstelle, Schichten, optional Code on Demand. Ressourcen sind fachliche Objekte, die eindeutig per URI identifiziert werden (z.B. https://api.shop.de/orders/42). Repräsentationen transportieren den Zustand, meist JSON oder XML, verhandelt über Content Negotiation via Accept und Content-Type. Methoden haben Semantik: GET ist sicher/idempotent, POST nicht idempotent, PUT idempotent, PATCH nicht zwingend idempotent, DELETE idempotent. Statuscodes signalisieren Ergebnis (200, 201, 204, 400, 401, 403, 404, 409, 500). HATEOAS bindet Navigations- und Aktionslinks in Repräsentationen ein. Effizientes Caching nutzt Cache-Control, ETag, Last-Modified und bedingte Anfragen.
Prüfungsrelevante Stichpunkte
- Ressourcenorientiertes API Design, Substantive/Plural, stabile URIs, keine Verben im Pfad
- HTTP Methoden und Semantik, sicher/idempotent/nicht-idempotent, Mapping auf CRUD
- Idempotenz sauber definieren, insbesondere für PUT, DELETE, POST mit Idempotency Key
- Statuscodes zielgerichtet verwenden, 2xx/3xx/4xx/5xx, Location Header bei 201
- Anforderungen an Datenschutz, Protokollierung, Nachvollziehbarkeit, Fehlercodes dokumentieren
- TLS erzwingen, OAuth 2/OIDC, JWT, CORS, Rate Limiting, Input Validierung, Logging
- Lose Kopplung, Wiederverwendung, unabhängige Weiterentwicklung von Client und Server
- OpenAPI-Dokumentation, Beispiel Requests/Responses, Fehlerkatalog, Versionsstrategie
Kernkomponenten
- Ressource und URI Design
- Repräsentationen, Medien-Typen und Schema
- Methoden Semantik: GET, POST, PUT, PATCH, DELETE
- Statuscodes und Header
- Content Negotiation: Accept, Content-Type, Accept-Language
- Caching: Cache-Control, ETag, Last-Modified, Conditional Requests
- Sicherheit: Authentisierung, Autorisierung, TLS, CORS
- Versionierung: URI, Header, Content-Types
- Beobachtbarkeit: Logging, Metriken, Tracing, Korrelations-ID
- Testverfahren: Contract Tests, API Tests, Fehlerpfade, Idempotenz Tests
Praxisbeispiel
// Beispiel: Bestellressource mit HATEOAS und Idempotenz
Ressourcen:
GET /orders - Liste der Bestellungen
POST /orders - neue Bestellung anlegen
GET /orders/{order-id} - Einzelbestellung lesen
PUT /orders/{order-id} - Bestellung vollständig ersetzen
PATCH /orders/{order-id} - Bestellung teilweise ändern
DELETE /orders/{order-id} - Bestellung löschen
Beispiel POST Anfrage:
{
"customerId": 12345,
"items": [{ "sku": "A1", "qty": 2 }]
}
Antwort 201 Created, Header: Location: https://api.shop.de/orders/42
Body:
{
"order-id": 42,
"status": "created",
"links": [
{ "rel": "self", "href": "https://api.shop.de/orders/42" },
{ "rel": "confirm", "method": "POST", "href": "https://api.shop.de/orders/42/confirm" }
]
}
Idempotenz bei POST: Client sendet zusätzlich Idempotency-Key: abc-123.
Server speichert Ergebnis pro Schlüssel, liefert bei Wiederholung dieselbe Antwort.
Vorteile und Nachteile
Vorteile
- Interoperabilität durch Standards
- Lose Kopplung, gute Skalierung durch Zustandslosigkeit
- Effizientes Caching, klare Fehlersignale über Statuscodes
- Einfache Nutzung durch Browser und Tools
Nachteile
- Overfetching und Underfetching möglich
- Komplexe Schreibprozesse erfordern saubere Idempotenz und Transaktionsstrategien
- HATEOAS wird oft vernachlässigt
- Sicherheitsverantwortung liegt stark beim API Design
- Bei Chatty APIs steigen Latenzen
Typische Prüfungsfragen (mit Kurzantwort)
- Sechs REST Constraints und Wirkung? Client-Server (unabhängige Entwicklung), Stateless (keine Sitzungszustände), Cacheable (wiederholte Antworten effizient), Uniform Interface (standardisierte Methoden), Layered (Intermediäre möglich), Code on Demand (optional Skripte).
- PUT vs. PATCH bei Idempotenz? PUT ersetzt vollständig und ist idempotent, PATCH ändert partiell und ist nicht zwingend idempotent.
- Safe für HTTP Methoden? Safe = keine zustandsverändernden Nebenwirkungen, GET und HEAD sind sicher (nur lesen).
- ETag und bedingte Anfragen? Server liefert ETag, Client sendet If-None-Match, bei Gleichheit antwortet Server mit 304 Not Modified ohne Body.
- REST API versionieren? URI-Versionen (/v1), Header-basiert, Accept-basiert (application/vnd.firma.resource.v2+json), wichtig: abwärtskompatible Änderungen.
- HATEOAS und Nutzen? Client entdeckt Aktionen über Links in Repräsentationen, reduziert Kopplung und harte Annahmen über Workflows.
- Content Negotiation in der Praxis? Client sendet Accept (application/json), Server wählt passende Repräsentation oder antwortet mit 406 Not Acceptable.
- Idempotente Schreiboperationen bei Zahlungen? POST auf Sammlungsressource mit Idempotency Key, dedizierte Transaktionsressource, Wiederholungen mit gleichem Schlüssel liefern denselben Endzustand:
/payments/{payment-id}