Fehlerbehandlung ajax//fetch

[dedlfix]

Tach!

aber nicht wirklich richtig.

Ja, bei der 400 hatte ich auch kein gutes Gefühl. Die 500 bei nicht behandelten Exceptions ist hingegen ziemlich klar.

HTTP Statuscodes beschreiben die Erfolge der Transportschicht. Falsche Eingaben sind Sache der Anwendung (nicht zu verwechseln mit OSI Application Layer) und eine Fehlermeldung im Sinne von "Bitte als Gewicht maximal 130kg eingeben" ist meiner Überzeugung nach eine HTTP 200 Response.

Wenn man mal ein normales Formular nimmt, dann antwortet man auch mit 200 und einer Seite, die eine Fehlermeldung nebst dem nochmal auszufüllenden Formular enthält. So müsste man das im Prinzip auch bei Ajax-Requests handhaben.

jemand ist am Ende mit HTTP 422 nach Hause gegangen

Die ist auch nicht so ganz klar, wohl eher für WebDAV gedacht. Am besten nimmt man da wohl die 418. Oder irgendeine unbenutzte Nummer.

Wenn man sich mal zur Abwechslung fetch() anschaut:

The Promise returned from fetch() won’t reject on HTTP error status even if the response is an HTTP 404 or 500. Instead, it will resolve normally (with ok status set to false), and it will only reject on network failure or if anything prevented the request from completing.

Das hat auch eine klare Meinung. Es ist immer erfolgreich, wenn der Server geantwortet hat. Das Bewerten des Inhalts der Antwort ist nicht mehr sein Thema. Trennung der Zuständigkeiten. Da muss man sich noch eine Schicht in die Architektur einziehen, wenn man das in Richtung der Anwendung anders und mehr aus ihrer Sicht kommunizieren möchte.

dedlfix.