Methoden, Statuscodes und Header

Methode, Statuscode und Header gehören zu den nützlichsten Signalen in HTTP-Anfragen und -Antworten. QA kann durch diese drei Elemente oft viel über ein Problem erfahren, noch bevor der Body gelesen wird.

Anfänger konzentrieren sich meist auf Antwortdaten: Kam JSON an, fehlt ein Feld oder ist es vorhanden? Das ist wichtig; grundlegender sind jedoch die Absicht des Clients, ihre Interpretation durch den Server und der technische Kontext der Anfrage. Methode, Statuscode und Header liefern diese Informationen.

Sichere Interpretation beschleunigt die Fehleruntersuchung erheblich.

Methode

Die HTTP-Methode drückt die Absicht des Clients aus: was er tun wollte, nicht das Ergebnis.

→GET — Daten abrufen.
→POST — eine Entität erstellen oder eine Aktion auslösen.
→PUT — eine Ressource vollständig ersetzen.
→PATCH — einen Teil einer Ressource aktualisieren.
→DELETE — eine Ressource löschen oder als inaktiv markieren.

Teams verwenden Methoden in der Praxis nicht immer perfekt; berücksichtigen Sie das. QA muss ihre Bedeutung dennoch kennen. Sendet ein Client GET und ändern sich dadurch Daten, ist das auffällig. Entitäten über GET anzulegen widerspricht API-Konventionen und Erwartungen an Caching, Wiederholbarkeit und sichere Methoden.

Ein weiteres wichtiges Konzept ist Idempotenz. Manche Methoden lassen sich ohne Änderung des beabsichtigten Ergebnisses wiederholen, andere nicht. Das ist bei Retries, Mehrfachklicks, instabilen Netzen und automatisierten Tests relevant. Dieselbe versehentlich doppelt gesendete Anfrage kann bei POST und PUT unterschiedliche Folgen haben; berücksichtigen Sie diese in den Prüfungen.

Statuscode

Ein Statuscode fasst die Verarbeitung einer Anfrage technisch knapp zusammen. Er erklärt nicht alles, benennt aber sofort die Ergebniskategorie.

→1xx — vorläufige technische Information.
→2xx — Anfrage erfolgreich verarbeitet.
→3xx — Weiterleitung oder zusätzlicher Schritt erforderlich.
→4xx — Problem mit Anfrage, Daten oder Zugriff des Clients.
→5xx — serverseitiger Fehler.

Diese Kategorien reichen für eine erste Einordnung. Erfahrene Tester kennen darüber hinaus die häufigsten einzelnen Codes.

→200 OK — Anfrage erfolgreich.
→201 Created — Entität erstellt.
→204 No Content — Operation erfolgreich, kein Antwortbody.
→301 / 302 / 307 / 308 — Weiterleitungen.
→400 Bad Request — Server akzeptiert die Anfrage in dieser Form nicht.
→401 Unauthorized — Client nicht korrekt authentifiziert.
→403 Forbidden — Client erkannt, aber ohne Zugriff.
→404 Not Found — Ressource nicht gefunden.
→409 Conflict — Zustandskonflikt.
→422 Unprocessable Content — Anfragestruktur gültig, aber Geschäftsbedeutung oder Daten bestehen die Validierung nicht.
→500 Internal Server Error — interner Serverfehler.
→502, 503, 504 — Probleme an Dienstgrenzen, Überlastung oder Nichtverfügbarkeit.

Ziel ist zu verstehen, wie Codes Probleme eingrenzen, nicht die gesamte Tabelle auswendig zu lernen.

401 und 403 bedeuten beispielsweise Unterschiedliches. 404 kann „URL existiert nicht“ oder „Entität existiert nicht“ heißen. 200 garantiert keine korrekte Geschäftslogik. 500 nennt nicht die genaue Fehlerstelle, zeigt aber schnell, dass das Problem über das Frontendformular hinausgeht.

Warum 200 OK allein wenig garantiert

Eine häufige Falle ist die Annahme, bei einer API-Antwort mit 200 sei alles in Ordnung.

→Falsche Daten zurückgeben.
→Eine leere Liste liefern, obwohl ein Objekt erwartet wird.
→Einen Geschäftsfehler in einem error-Feld verstecken.
→Eine Operation nur teilweise ausführen.
→Veraltete Daten aus einem Cache liefern.

QA interpretiert den Statuscode deshalb immer zusammen mit Antwortbody und Szenariokontext. Technischer Erfolg bedeutet nicht zwangsläufig korrektes Produktverhalten.

Header liefern zusätzlichen Kontext für Anfrage und Antwort. Sie wirken oft nebensächlich, bis reale Probleme untersucht werden.

→Datentyp (Content-Type).
→Erwartetes Antwortformat (Accept).
→Autorisierung (Authorization).
→Cookies.
→Sprache oder Sprachregion.
→Caching (Cache-Control, ETag, If-None-Match).
→Korrelationskennungen.
→CORS-Richtlinien.
→Sicherheitsrichtlinien.

Header sind für QA besonders wichtig, weil sie häufig scheinbar „seltsame“ Fehler erklären.

→Das Backend erwartet application/json, der Client sendet einen anderen Content-Type.
→Ein Token ist vorhanden, wurde aber im falschen Header gesendet.
→Ein Cookie kam nicht an oder wurde nicht gespeichert.
→Der Cache lieferte eine alte Datenversion.
→Der Browser blockierte wegen CORS eine Anfrage.
→Ein Reverse Proxy schrieb Header um.
→Die Anfrage nennt eine Sprachregion, die Antwort verwendet eine andere.

Header sind ein wesentlicher Protokollbestandteil: Sie transportieren entscheidenden Kontext. Ohne ihn kann eine Anfrage technisch gültig, aber logisch falsch sein.

Praktischer Nutzen für QA

Betrachten Sie einen Fehler: Ein Benutzer kann sein Profil nicht speichern.

Das UI zeigt nur eine Fehlermeldung. HTTP-Signale können völlig unterschiedliche Situationen aufdecken:

→Eine PATCH-Anfrage wurde gesendet, der Server lieferte wegen eines ungültigen Feldes 400.
→Die Anfrage wurde als POST gesendet, obwohl das Backend PATCH erwartet.
→Der Server lieferte 403, weil der Rolle die Berechtigung fehlt.
→Der Client sendete den falschen Content-Type.
→Die Operation gelang, aber das Frontend kann 204 No Content nicht verarbeiten.
→Die Anfrage gelingt, aber Cache oder Neuladen zeigen alte Daten.

Alles kann wie ein einziger Fehler „Profil wird nicht gespeichert“ aussehen. Für das Team sind es sechs verschiedene Problemklassen. Methode, Statuscode und Header zeigen die Untersuchungsrichtung.

Was QA prüfen sollte

→Welche Methode verwendet wurde.
→Welche URL aufgerufen wurde.
→Welche wichtigen Header gesendet wurden.
→Welcher Statuscode zurückkam.
→Welche Header zurückkamen.
→Ob der Body zur Bedeutung des Szenarios passt.

Mit einem systematischen Ansatz werden Netzwerkprotokolle vom „Rauschen“ zu einer erkennbaren Struktur.

Wichtig für QA

→Die Methode drückt die Absicht des Clients aus.
→Der Statuscode meldet das technische Verarbeitungsergebnis.
→Header vermitteln wesentlichen Kontext für Anfragen und Antworten.
→200 OK garantiert keinen korrekt abgeschlossenen Geschäftsablauf.
→Viele Defekte lassen sich leichter eingrenzen, wenn Methode, Status und Header gemeinsam interpretiert werden.

Weiterführende Informationen

→In dieser Wissensdatenbank: HTTP und HTTPS
→In dieser Wissensdatenbank: Authentifizierung und Autorisierung
→Externe Ressource: MDN: HTTP-Antwortstatuscodes