REST API

Postman oder curl sind deine Tools. Request:

GET /api/v1/products/42 HTTP/1.1
Authorization: Bearer mytoken
Accept: application/json

Response:

HTTP/1.1 200 OK
Content-Type: application/json

{ "id": 42, "name": "Kaffee", "price": 2.50 }

Status Codes sind wichtig: 200 (OK), 201 (Created), 400 (Bad Request), 401 (Unauthorized), 404 (Not Found), 500 (Server Error).

Praxisroutine

In der Praxis lernst du REST API, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. HATEOAS (Hypermedia)

Das "H" in REST, das alle ignorieren. "Hypermedia As The Engine Of Application State". Die API sollte nicht nur Daten liefern, sondern auch Links ("Was kann ich als nächstes tun?").

{
  "id": 42,
  "balance": 0,
  "_links": {
    "deposit": "/users/42/deposit",
    "close_account": "/users/42/close"
  }
}

Damit muss der Client die URLs nicht hardcoden. Er navigiert wie ein Mensch im Browser.

2. Idempotenz

Ein Idempotenter Request kann 10x gesendet werden, und das Ergebnis ist gleich wie beim 1. Mal.

• GET: Ja (Lesen ändert nichts).
• PUT: Ja ("Setze Name=Hans". Auch beim 10. Mal ist Name=Hans).
• DELETE: Ja (Wenn weg, dann weg. 2. Löschen gibt 404, ändert aber nichts).
• POST: Nein! ("Erstelle Bestellung". 10x POST = 10 Bestellungen!). Lösung für instabile Netze: Idempotency Keys. Client sendet X-Idempotency-Key: uuid-123. Server merkt sich: "UUID 123 habe ich schon bearbeitet", und ignoriert das Duplikat.

3. Versionierung

APIs ändern sich. Wie brichst du alte Apps nicht?

• URL Versioning: /api/v1/users (Am beliebtesten).
• Header Versioning: Accept: application/vnd.myapi.v1+json. (Sauberer im REST-Sinne, aber schwerer zu testen). Niemals Breaking Changes ohne neue Version!

1. N+1 Problem (Underfetching in SQL)

Der Klassiker in REST: Du fragst den /api/users Endpoint an und bekommst 100 User als JSON-Array zurück. Nun brauchst du zu jedem User seine Profildaten (Wohnort). Die klassische REST-Abstraktion (jeder Resource-Typ hat seinen eigenen Endpunkt) zwingt das Frontend nun dazu, asynchron 100 individuelle GET /api/users/1/profile bis /api/users/100/profile Requests auf das Backend abzufeuern. Der Browser implodiert wegen Connection Overhead. Das Backend führt hinten 100 einzelne SQL Selects durchstatt eines sauberen LEFT JOIN (Das berüchtigte N+1 Query Problem). Die Rettung in pragmatischen (aber "unreinen") REST APIs sind Query-Parameter-Expansions: GET /users?embed=profile. Dies bricht die akademische Ressourcen-Regel des strikten Resource-Routings zugunsten der Performance (Graph-Ansatz) radikal auf.

2. ETag und Conditional Requests (Bandbreiten-Kollaps)

Gigantische JSON Payloads ("Die Konfig der gesamten App", 2 Megabyte) oft abzurufen, grillt den Mobil-Tarif. Gutes REST Caching funktioniert nicht über pure Zeit-Abläufe (Expiration), sondern bedingt (Conditional). Der Server sendet beim ersten GET den 2MB Body plus einen ETag-Header (z.B. den MD5-Hash des JSONs W/"0815"). Beim Neustart der Smartphone-App sendet diese später den Cache-Header If-None-Match: "0815". Die Backend-DB checkt in Nanosekunden: Hat sich die Konfig intern seit "0815" verändert? Nein. Anstatt 2MB Text durch das Kupferkabel zu quetschen, sendet der REST API Node einen nackten HTTP Status 304 Not Modified zurück (Header ohne Body). Das spart unglaubliche Netzwerkressourcen im Edge Node.

3. API Contract Testing vs Spec-Drift (Swagger/OpenAPI)

Das Frontend (React) wird ausgeliefert gegen REST API V1. 3 Wochen später fügt ein Backend-Entwickler "kurz" ein Enum-Feld (status=ARCHIVED) hinzu und pushed. Die React-App crasht live. Die API Spezifikation (Swagger Docs) und die physikalische PHP/Java-Implementierung sind "gedriftet" (Spec-Drift). Profi-Lösung: Consumer-Driven Contract Testing (Pact / Dredd). Das API-Design wird in YAML geschrieben (OpenAPI 3.0), noch bevor ein Entwickler gecoded hat ("Design First"). In der CI/CD Pipeline validiert ein Proxy-Robot den Live-Code im Docker-Container gegen das YAML-Regelwerk. Weicht der JSON Response-Typ (Feld Name fehlend) von der Specs-Verfassung ab, scheitert der Deployment Build automatisch tiefrot. Eine Garantie dafür, dass die Clients sich nicht verschlucken.