HTTP-Methoden und Statuscodes vertieft

In L1 hast du gesehen, dass REST auf HTTP aufbaut. In K50 L8 haben wir die Grundverben GET, POST, PUT, PATCH, DELETE und ein paar Statuscodes kennengelernt. Diese Lektion geht in die Tiefe: alle HTTP-Methoden mit ihren Eigenschaften (sicher / idempotent), die kompletten Statuscode-Familien, die wichtigsten Header und die typischen Fallstricke der Praxis.

Warum so genau? Weil in einer professionellen REST-API jeder Statuscode, jeder Header und jede Methode genau das richtige Signal sendet. Wer hier nachlässig ist, produziert APIs, die schwer zu bedienen sind, mit Caches Probleme haben, und sich auf merkwürdige Weise verhalten – Bugs, die in der Klausur und im Berufsalltag beide Punkte kosten.

1) Die HTTP-Methoden-Matrix

HTTP definiert mehr als die fünf REST-Klassiker. Jede Methode hat klar definierte Eigenschaften – ob sie Daten verändert (safe), ob mehrfaches Ausführen denselben Effekt hat (idempotent) und ob sie einen Body haben darf. Diese Eigenschaften sind keine bloße Theorie: sie steuern, ob Browser cachen, ob Proxies wiederholen dürfen, ob Netzwerk-Tools Retries machen.

2) Idempotenz konkret – warum sie wichtig ist

Idempotenz klingt akademisch, ist aber im echten Leben Gold wert. Stell dir vor, dein Browser schickt POST /payments ab, um 100 € zu überweisen. Das Netz hängt, du klickst noch mal. Soll die Bank jetzt 200 € abbuchen? Nein – ein gutes Design verhindert das. Genau das macht Idempotenz: derselbe Aufruf mehrfach hat denselben Effekt wie einmal.

Eine Analogie: ein Lichtschalter hat zwei idempotente Operationen – „auf An stellen" und „auf Aus stellen". Wer den Schalter zehnmal auf An stellt, hat dasselbe Ergebnis wie wer ihn einmal auf An stellt. Nicht idempotent wäre dagegen „Schalter umlegen" – das Ergebnis hängt davon ab, wie oft man's macht.

3) Die Statuscode-Landkarte

HTTP-Statuscodes sind dreistellige Zahlen, gruppiert nach der ersten Ziffer. In K50 L8 haben wir die wichtigsten kennengelernt – hier eine erweiterte Karte mit den Codes, die in echten APIs regelmäßig auftauchen:

4) Die wichtigsten Codes im Detail

Einige Codes sind so wichtig, dass sie ihre eigenen Eigenheiten haben. Diese sind klausurrelevant und tauchen täglich im Berufsalltag auf:

• 201 Created vs. 200 OK: nach erfolgreichem POST ist 201 die richtige Antwort – plus ein Location-Header mit der URL der neu erstellten Ressource. 200 OK ist zwar nicht falsch, aber weniger präzise.
• 204 No Content: erfolgreich, aber kein Body. Standard nach DELETE und manchmal nach PUT. Spart Bandbreite, signalisiert klar: alles ok, nichts mehr zu sagen.
• 304 Not Modified: der Client hatte mit If-None-Match oder If-Modified-Since nach einer aktuellen Version gefragt. Antwort: „du hast schon die aktuelle Version, nutz deinen Cache." Spart massiv Bandbreite.
• 401 vs. 403: 401 Unauthorized heißt „ich weiß nicht, wer du bist" (Token fehlt / abgelaufen). 403 Forbidden heißt „ich weiß, wer du bist, aber du darfst das nicht". Häufig verwechselt – siehe auch L4 Authentifizierung.
• 422 Unprocessable Entity: die Anfrage ist syntaktisch ok (gültiges JSON), aber semantisch falsch (z.B. „E-Mail-Adresse ohne @"). Klare Unterscheidung zu 400 (Bad Request = schon Syntax kaputt).
• 429 Too Many Requests: Rate-Limit überschritten – siehe L8. Antwort enthält oft den Header Retry-After.
• 503 Service Unavailable: Server ist überlastet oder in Wartung. Vorübergehend – Client darf später erneut versuchen.

5) HTTP-Header – die unterschätzte Hälfte

Eine HTTP-Nachricht hat nicht nur Methode, URL, Statuscode und Body. Sie hat auch Header – Schlüssel-Wert-Paare mit Metadaten. In professionellen APIs spielen sie eine zentrale Rolle: Authentifizierung, Format-Verhandlung, Caching, Rate-Limiting, Tracing – all das läuft über Header. Hier die wichtigsten:

6) Ein vollständiger Request mit allen Bestandteilen

Schauen wir uns einen realistischen API-Request mit allen Bestandteilen an – Request-Line, Header, Body und die zugehörige Response. So sieht das aus, wenn ein Client ein neues Produkt anlegt:

7) Method-Quiz: was ist die richtige Antwort?

Teste dich selbst – welcher Statuscode passt jeweils? Wähle aus den Optionen:

8) Häufige Fehler in der Praxis

Diese Anti-Patterns siehst du in „okay" APIs, in „guten" APIs nicht. Sie kosten in IHK-Klausuren Punkte und im Berufsalltag Nerven:

• 200 OK bei Fehlern. „Der Server hat ja geantwortet" – nein, der Server muss auch sagen, ob's geklappt hat. Statuscodes sind dazu da.
• POST für alles. „Ich nutze immer POST, weil ich Body senden kann" – verstößt gegen REST. PUT, PATCH, DELETE haben jeweils eigene Bedeutung und Eigenschaften (Idempotenz).
• Verben in der URL. /getProduct/42 oder /deleteUser/7. URL = Substantiv, Verb = HTTP-Methode. Faustregel aus K50 L8.
• Fehlende Content-Type-Header. Client schickt JSON ohne Content-Type: application/json – Server parst es als Form-Data. Häufiger Bug in handgeschriebenen Clients.
• 500 statt 400. Server bekommt ungültiges JSON und antwortet mit „Internal Server Error" – sollte 400 sein, weil der Client schuld ist.
• Eigene Status-Wörter im Body. {"success": true} oder {"status": "error"} – ist redundant zum HTTP-Statuscode und führt zu Inkonsistenzen.

9) CORS – warum Browser besondere Regeln haben

Ein Thema, das früher oder später jeden API-Entwickler trifft: CORS (Cross-Origin Resource Sharing). Browser haben eine Sicherheitsregel namens Same-Origin Policy: eine Webseite auf shop.example.com darf standardmäßig keine Anfragen an api.example.com stellen. Das schützt vor diversen Angriffen.

Wenn deine API von einer anderen Domain aufgerufen werden soll, muss der Server CORS-Header setzen, die das ausdrücklich erlauben. Wichtigster Header: Access-Control-Allow-Origin. Der Browser sendet vor potentiell „gefährlichen" Aufrufen (z.B. POST mit JSON-Body) eine OPTIONS-Preflight-Anfrage – die API muss die richtigen CORS-Header zurückgeben, sonst blockt der Browser den eigentlichen Aufruf.

Wichtig zu wissen: CORS ist eine Browser-Sicherheit. Curl, Postman, dein Backend ignorieren CORS komplett. Wenn deine API in Postman funktioniert, aber im Browser nicht – CORS ist meist die Antwort. Vertiefung in K11 Secure Coding.

10) Zusammenfassung für die Klausur

Was du aus dieser Lektion mitnehmen solltest, kompakt:

• 7 HTTP-Methoden: GET, HEAD, OPTIONS, POST, PUT, PATCH, DELETE. Eigenschaften: safe (verändert nichts) und idempotent (mehrfach = einmal).
• Idempotent: GET, HEAD, OPTIONS, PUT, DELETE. Nicht idempotent: POST. PATCH je nach Implementierung.
• 4 Statuscode-Gruppen: 2xx Erfolg, 3xx Umleitung, 4xx Client-Fehler, 5xx Server-Fehler. Faustregel: 4xx = du, 5xx = ich.
• Wichtigste Codes: 200, 201, 204, 301, 304, 400, 401, 403, 404, 409, 422, 429, 500, 503.
• 401 vs. 403: 401 = nicht eingeloggt, 403 = eingeloggt aber keine Rechte.
• Wichtigste Header: Content-Type, Accept, Authorization, Cache-Control, ETag, Location, Retry-After.
• CORS: Browser-Sicherheit gegen cross-origin Aufrufe. OPTIONS-Preflight + Access-Control-Allow-Origin.

Zusammenfassung

HTTP hat 7 Methoden: GET, HEAD, OPTIONS (alle safe und idempotent), POST (erstellen, nicht idempotent), PUT (ersetzen, idempotent), PATCH (teil-ändern), DELETE (idempotent). Safe = verändert nichts. Idempotent = mehrfaches = einmaliges Ausführen. Der Idempotency-Key-Header schützt POSTs vor Duplikaten (z.B. Zahlungen). Statuscode-Gruppen: 2xx Erfolg (200/201/204), 3xx Umleitung (301, 304), 4xx Client-Fehler (400/401/403/404/409/422/429), 5xx Server-Fehler (500/502/503). 401 vs. 403: 401 = Auth fehlt, 403 = keine Berechtigung. Niemals 200 bei Fehlern. Wichtige Header: Content-Type, Accept, Authorization, Cache-Control, ETag, Location, Retry-After, X-Request-ID. CORS: Browser-Sicherheit gegen Cross-Origin-Aufrufe, OPTIONS-Preflight + Access-Control-Allow-Origin. Mehr Sicherheit in K11 Secure Coding. Nächste Lektion: RESTful API designen.