REST Grundlagen
Dieser Beitrag ist eine Begriffserklärung zu REST – inklusive Prüfungsfragen, Praxisbeispiel und Tags.
In a Nutshell
REST ist ein Architekturstil für verteilte Systeme auf HTTP-Basis: Ressourcen werden über URIs adressiert, per Methoden manipuliert und über Repräsentationen übertragen. Ziel: lose Kopplung, Skalierbarkeit, Caching.
Kompakte Fachbeschreibung
REST definiert sechs Constraints:
- Client-Server
- Zustandslosigkeit
- Cache-Fähigkeit
- Einheitliche Schnittstelle
- Schichten
- optional Code on Demand
Ressourcen sind fachliche Objekte (z.B. /orders/42). Repräsentationen transportieren Zustand (JSON/XML), verhandelt über Accept/Content-Type.
Methoden-Semantik:
- GET: safe + idempotent
- POST: nicht idempotent
- PUT: idempotent
- PATCH: nicht zwingend idempotent
- DELETE: idempotent
Statuscodes signalisieren Erfolge/Fehler (200/201/204/400/401/403/404/409/500). HATEOAS nutzt Links in Repräsentationen für „entdeckbare“ Workflows. Caching nutzt Cache-Control, ETag, If-None-Match.
Prüfungsrelevante Stichpunkte
- Ressourcenorientiertes URI-Design (keine Verben im Pfad)
- Safe/Idempotent-Semantik von Methoden
- Statuscodes korrekt (Location bei 201)
- Idempotency Key für POST (wenn nötig)
- Security: TLS, OAuth/OIDC/JWT, CORS, Rate Limiting
- Wirtschaftlichkeit: lose Kopplung
- Doku: OpenAPI + Fehlerkatalog
Kernkomponenten
- Ressource + URI-Design
- Repräsentationen + Medientypen
- Methoden-Semantik
- Statuscodes + Header
- Content Negotiation
- Caching (ETag)
- Security
- Versionierung
- Observability
- Tests (Contract/API)
Praxisbeispiel (Orders + HATEOAS)
{
"id": 42,
"status": "created",
"links": [
{ "rel": "self", "href": "/orders/42" },
{ "rel": "confirm", "method": "POST", "href": "/orders/42/confirm" }
]
}
Vorteile und Nachteile
Vorteile
- Interoperabilität durch Standards
- Lose Kopplung
- Gute Skalierung durch Statelessness
- Effizientes Caching
Nachteile
- Overfetching/Underfetching möglich
- Komplexe Schreibprozesse erfordern Idempotenz-Strategien
- HATEOAS wird häufig nicht konsequent genutzt
Typische Prüfungsfragen (mit Kurzantwort)
- Welche REST-Constraints gibt es? Client-Server, Stateless, Cache, Uniform Interface, Layered, optional Code on Demand.
- PUT vs PATCH bzgl. Idempotenz? PUT idempotent, PATCH nicht automatisch.
- Wie funktionieren ETag + bedingte Anfragen?
Client sendet
If-None-Match, Server antwortet 304 oder liefert neuen Body.
Freie Antwort
REST ist mehr als „JSON über HTTP“: die Constraints und die Methodensemantik sind entscheidend. Saubere Fehlerobjekte, Versionierung und Observability machen APIs wartbar.
Lernstrategie
- Öffentliche API analysieren und Constraints zuordnen.
- Ressourcenmodell entwerfen (URIs/Methoden/Statuscodes).
- Tabelle Methodensemantik (safe/idempotent) üben.
- Verben im Pfad vermeiden.