讨论： HTTP-Statuscodes richtig verwenden: die erste Verzweigung des Clients

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

暂无译文，显示原文。 原文

«Ein 200 mit Fehlerobjekt täuscht alle» ist als Regel gegen das Verstecken von Fehlern richtig und lässt einen Fall aus, der in APIs häufig ist: die Antwort mit Teilerfolg. Eine Stapelanfrage, die hundert Datensätze anlegt, von denen drei scheitern, kann weder ehrlich 201 noch ehrlich 422 antworten; GraphQL liefert Feldfehler absichtlich in einem 200 mit einer `errors`-Liste neben `data` (die GraphQL-over-HTTP-Spezifikation reserviert 4xx für Anfragen, die als Ganzes ungültig sind), und WebDAV hat für dieselbe Lage 207 Multi-Status mit einem Status pro Element definiert. Wer die Regel des Artikels wörtlich nimmt, baut Stapelendpunkte, die beim ersten Fehler alles verwerfen, oder erfindet einen eigenen Code. Die brauchbare Fassung lautet: Der Statuscode beschreibt die Anfrage als Ganzes, jedes Element trägt seinen eigenen Status im Körper, das Format dafür steht in der Dokumentation, und das Monitoring zählt Elementfehler getrennt von Anfragefehlern. So bleibt die Aussage «200 heisst: die Anfrage wurde verarbeitet» wahr, ohne dass Fehler verschwinden.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

暂无译文，显示原文。 原文

Einige Details aus RFC 9110 und der Praxis zu den genannten Codes. 422 heisst in RFC 9110 «Unprocessable Content» (früher «Unprocessable Entity» aus RFC 4918) und ist damit erstmals Teil der HTTP-Kernspezifikation, nicht mehr nur von WebDAV. Ein 405 muss einen `Allow`-Header mit den zulässigen Methoden tragen, so wie ein 401 `WWW-Authenticate` braucht. `Retry-After` ist auch bei Umleitungen erlaubt, um eine Mindestwartezeit vor dem Folgen anzugeben, und akzeptiert Sekunden ebenso wie ein HTTP-Datum. Welche Codes «viele Clients wiederholen», lässt sich an dokumentierten Clients festmachen: curl wiederholt mit `--retry` nur bei Timeouts und bei 408, 429, 500, 502, 503 und 504 und hält sich seit 7.66.0 an `Retry-After`; die offiziellen Anthropic-SDKs wiederholen standardmässig zweimal bei 408, 409, 429 und 5xx sowie bei Verbindungsfehlern. Ein 400 oder 422 wiederholt keiner dieser Clients, was die Trennung im Artikel praktisch begründet.