HTTP Method

Die wichtigsten für REST APIs:

1. GET: Lesen. Sicher (ändert nichts am Server).
2. POST: Erstellen (Create). Nicht idempotent (2x senden = 2x erstellen).
3. PUT: Ersetzen (Update). Überschreibt das ganze Objekt.
4. PATCH: Ändern (Update). Ändert nur Teile (z. B. nur Email ändern).
5. DELETE: Löschen.

Browser nutzen fast nur GET und POST. Apps (Mobile, SPA) nutzen alle.

Praxisroutine

In der Praxis lernst du HTTP Method, 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. Safe vs. Idempotent

Das ist Prüfungsstoff.

• Safe Methods (GET, HEAD, OPTIONS): Dürfen nichts ändern (Read-Only). Ein Crawler (Google Bot) darf sie millionenfach aufrufen, ohne dass du was kaufst.
• Idempotent Methods (PUT, DELETE): Wenn ich sie 10x sende, ist das Ergebnis das gleiche wie beim 1. Mal. DELETE /users/1 -> User weg. Nochmal DELETE /users/1 -> User immer noch weg (404). Zustand ist gleich geblieben.
• POST ist nicht idempotent! (Doppelte Buchung möglich).

2. OPTIONS & CORS

Ein unsichtbarer Held. Bevor dein Browser einen Cross-Origin Request (von a.com nach api.b.com) mit PUT sendet, macht er automatisch einen Preflight Request. OPTIONS /api/users. Server antwortet: Allow: GET, POST, PUT. Erst dann schickt der Browser das echte PUT. Ohne OPTIONS kein modernes Web mit React/Angular.

3. HEAD

Wie GET, aber der Server sendet nur Header, keinen Body (Inhalt). Nützlich für:

• "Existiert die Datei?" (Check Links).
• "Wie groß ist der Download?" (Content-Length).
• "Hat sich was geändert?" (Last-Modified). Spart enorm Bandbreite bei Sync-Clients.

1. Die Semantik von PUT vs PATCH (Im Detail)

Das RFC für PUT verlangt strikt eine komplette Repräsentation der Ziel-Ressource. Sendest du PUT /user/1 mit {"name": "Max"}, aber der User hat in der DB noch {"age": 30}, muss der Backend-Developer (laut HTTP/REST Spezifikation) das Alter auf NULL setzen, weil es im Request fehlte. PUT ist ein Replacement. PATCH hingegen verlangt historisch ein Diff-Dokument. Der Content-Type application/json-patch+json (RFC 6902) erwartet strukturierte Operationen: [ { "op": "replace", "path": "/name", "value": "Max" } ]. In der Praxis ignorieren 90% der Web-Entwickler das RFC und schicken per PATCH einfach rudimentäres JSON, das Backend merded es. So hat sich der pragmatische "Merge-Patch" (RFC 7396) eingebürgert.

2. Idempotency Keys (Bei POST)

Wenn POST nicht idempotent ist (es erstellt Dinge), was passiert bei einer schlechten Handyverbindung? Der User klickt "Bezahlen" (POST). Backend bucht 50€. Die Antwort (200 OK) geht im Mobilfunkmast verloren. Das UI des Users lädt ewig, er drückt noch mal "Bezahlen". Wieder 50€ weg. Gute APIs (wie Stripe) erzwingen Idempotency Keys. Der Client generiert eine UUID (Idempotency-Key: a4c9...) und klebt sie als Header an das POST. Der Server bookt die 50€ ein, und merkt in Redis: "Key a4c9 hat bereits 200 OK generiert". Kommt das selbe POST vom ungeduldigen User eine Sekunde später noch mal, macht der Server nichts, sondern spuckt aus dem Cache die alte Erfolgsmeldung 200 OK (Replay).

3. WebDAV Methoden (Die vergessenen Verben)

Die Welt denkt, HTTP hätte nur 5 Verben. Das Protokoll ist aber absolut erweiterbar. WebDAV (eine HTTP-Zusatzspezifikation, auf welcher z.B. Nextcloud oder CalDAV basieren) erfand ein halbes Dutzend neue Methoden. PROPFIND holt Datei-Metadaten in XML. COPY und MOVE machen genau das, was der Name im Filesystem sagt. LOCK sperrt die Datei für andere Editoren. Ein reiner REST Purist lacht darüber, aber WebDAV macht HTTP zum vollwertigen Netzlaufwerk.