it-swarm.com.de

HTTP-Statuscode für Ausnahmen

ich habe einen SpringBoot-Controller und möchte den korrekten http-Code-Status für Ausnahmen zurückgeben. Meine Frage ist also: Welcher http-statocode ist besser für die Ausnahme "500" oder "409"?

Das ist mein Code:

@PostMapping(value = {"", "/"})
public ResponseEntity<Response> create(@RequestBody StudioDto studioDto,
        ServletRequest servletRequest, ServletResponse servletResponse) {

    Response response = new Response();

    try {
        studioService.createStudio(studioDto);
        response.setMessage("The studio was create");
        response.setStatusCode(HttpServletResponse.SC_CREATED);

    } catch (Exception e) {
        response.setMessage("Op we have a little problem");
        response.setErrorMessage(e.getMessage());

        //Which one
        //this one 5xx
        response.setStatusCode(500);
        //Or this one 4xx
        response.setStatusCode(409);
    }

    return new ResponseEntity(response, response.getHttpStatus());
}
6
Carlos Mario

Dies ist nicht die empfohlene Möglichkeit, mit Ausnahmen umzugehen. Sie sollten den Controller-Hinweis verwenden. Überprüfen Sie diesen Link .

Der Statuscode wird durch das spezifische Szenario definiert. 500 bedeutet, dass ein interner Serverfehler, den ich für ein Problem verwenden würde, dessen Ursache nicht angegeben ist, für 409 einen Konflikt auf der Zielressource darstellt

Die Anforderung konnte aufgrund eines Konflikts mit dem aktuellen Status der Zielressource nicht abgeschlossen werden. Dieser Code wird in Situationen verwendet, in denen der Benutzer den Konflikt möglicherweise lösen und die Anforderung erneut senden kann

sie haben viele andere Statuscodes, die in verschiedenen Fällen geeignet sind. Daher würde ich sagen, dass kein bestimmter Statuscode die richtige Antwort ist. Sie können diesen Link überprüfen, um weitere Informationen zu erhalten die Info

2
Amer Qarabsa

Todd hat eine tolle Verbindung gegeben. Dies ist eine bessere Art, darüber nachzudenken:

https://httpstatuses.com/

  • 1 × × informativ

  • 2 × x Erfolg

  • 3 × × Umleitung

  • 4 × × Client-Fehler * 400 Fehlerhafte Anforderung * 401 Nicht autorisiert ... * 405 Methode nicht zulässig ...

  • 5 × × Server-Fehler * 500 Interner Server-Fehler * 501 Nicht implementiert * 502 Fehlerhaftes Gateway ...

Mit anderen Worten ist jede Hauptnummer (200, 400, 500 usw.) eine -KATEGORIE. Sie können den Fehlercode "verfeinern", indem Sie einen bestimmten Fehler in der "Kategorie" auswählen.

Zu Ihrer ursprünglichen Frage:

  • Wenn die Client-Anforderung "schlecht" ist (z. B. unzulässiger Benutzername/Passwort), geben Sie eine 4xx zurück.

  • Wenn Server irgendwie fehlschlägt (Sie können die Datenbank beispielsweise nicht lesen), geben Sie 5xx zurück.

Die "offizielle" Liste der HTTP-Fehlercodes lautet RFC 7231:

https://tools.ietf.org/html/rfc7231

4
paulsm4

Es hängt davon ab, welche Nachricht Sie vermitteln möchten. Stellen Sie sich den Statuscode als Anleitung für den Anrufer vor, was als Nächstes zu tun ist. Wenn es sich um einen internen Serverfehler handelt, über den der Benutzer wahrscheinlich nichts unternehmen kann, ist der Fehler a 500 angebracht.

Der Server hat eine unerwartete Bedingung festgestellt, durch die die Anforderung nicht erfüllt werden konnte.

Andererseits zeigt a 409 einen Konflikt an, den der Benutzer konzeptionell lösen könnte:

Die Anforderung konnte aufgrund eines Konflikts mit dem aktuellen Status der Zielressource nicht abgeschlossen werden. Dieser Code wird in Situationen verwendet, in denen der Benutzer den Konflikt möglicherweise lösen und die Anforderung erneut senden kann.

Die meisten Fehler der Stufe 400 deuten an, dass der Benutzer sie theoretisch beheben und erneut senden konnte.

Ich persönlich würde Ihnen raten, genauere Ausnahmen zu finden und zu bestimmen, welchen Statuscode jeder zurückgeben soll, da dies wirklich von Ihrem Anwendungsfall abhängt. Ab jetzt fangen Sie Exception, und das könnte alles sein, daher ist es schwer zu sagen, welche Art von Anleitung Sie dem Anrufer geben sollten.

1
Todd

5.XX-Codes bedeuten Fehler auf der Serverseite und 4.XXX-Codes bedeuten Fehler auf der Clientseite.
Hier fangen Sie jede Ausnahme auf:

 catch (Exception e) {
    response.setMessage("Op we have a little problem");
    response.setErrorMessage(e.getMessage());

    //Which one
    //this one 5xx
    response.setStatusCode(500);
    //Or this one 4xx
    response.setStatusCode(409);
}

Daher ist es ist eindeutig unmöglich zu wissen, ob das Problem von der Clientanforderung (beispielsweise fehlerhafte Parameter) oder von einem Serverfehler (Inkonsistenz in der Datenbank oder beispielsweise Programmfehler) herrührte.

Um mit der Genauigkeit 4.XXX oder 5.XXX festlegen zu können, kann Ihr Code auf bestimmte Basisausnahmen wie ClientErrorException und ServerErrorException angewiesen sein.

Werfen Sie den einen oder anderen nach der Fehlerursache und Sie können sich darauf verlassen, dass sie den korrekten Statuscode festlegen:

try {
    studioService.createStudio(studioDto);
    response.setMessage("The studio was create");
    response.setStatusCode(HttpServletResponse.SC_CREATED);
} 
 catch (ClientErrorException e) {
    response.setStatusCode(409);
}
catch (ServerErrorException e) {
    response.setStatusCode(500);
}

Eine andere Möglichkeit könnte darin bestehen, das Statuscodefeld in der Ausnahmebasisklasse hinzuzufügen.
Sie könnten so einfach schreiben:

try {
    studioService.createStudio(studioDto);
    response.setMessage("The studio was create");
    response.setStatusCode(HttpServletResponse.SC_CREATED);

} 
 catch (MyRestException e) {
    response.setStatusCode(e.getStatusCode());
}

Diese benutzerdefinierten Ausnahmen können direkt aus Ihrem Code ausgelöst werden, wenn Sie einen Fehler in der Clientanforderung feststellen (4.XXX).
Auf diese Weise könnten Sie alle anderen Ausnahmen als in Bezug auf die Serververarbeitung (5.XXX) betrachten.
Ein Spring-Exception-Handler könnte diese Aufgabe leicht ausführen.

1
davidxxx