Le code d'état Http pour les Exceptions

j'ai un SpringBoot contrôleur, et je veux rentrer le bon code http statut pour les Exceptions. Donc, ma question est: Qui http statu code est mieux pour Exception le "500" ou "409"?

C'est mon 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());
}

Une indication approximative que j'utilise est le suivant: Réfléchir à de nouvelles tentatives. Si il y a une chance qu'une nouvelle tentative avec la même demande sera couronnée de succès, c'est un 5xx (exemple: problème de connectivité de base de données qui a été résolu quelques secondes plus tard). Si une nouvelle tentative avec la même demande sera toujours à l'origine de cette erreur, c'est un 4xx (exemple: champ non valide dans la demande). De cette façon, un client sait si cela a un sens pour réessayer ou pas.

OriginalL'auteur Carlos Mario | 2018-01-07

2

Ce n'est pas la méthode recommandée pour traiter les exceptions, vous devez utiliser le contrôleur de conseils , consultez cette lien

Le code de statut est défini par le scénario spécifique , 500 signifie erreur interne du serveur qui je voudrais l'utiliser pour un problème dont la cause n'est pas spécifié, pour 409 il resembels conflit sur la ressource cible

La demande n'a pas pu être terminé en raison d'un conflit avec le courant
état de la ressource cible. Ce code est utilisé dans les situations où
l'utilisateur peut être en mesure de résoudre le conflit et de le soumettre de nouveau
demande

vous avez de nombreux autres codes d'état qui convient dans de nombreux cas, donc je dirais pas de code de statut spécifique est la bonne réponse, vous pouvez vérifier ce lien pour plus d'info

OriginalL'auteur Amer Qarabsa
5

Todd a donné un grand lien. C'est une meilleure façon de penser à ce sujet:
https://httpstatuses.com/
- 1×× Information
- 2×× Succès
- 3×× Redirection
- 4×× Erreur Du Client * 400 Bad Request * 401 Non Autorisé
  ... * 405 Method Not Allowed
  ...
- 5×× Erreur De Serveur * 500 Erreur Interne Du Serveur * 501 Pas Mis En Œuvre * 502 Bad Gateway ...
En d'autres termes, chaque nombre important (200, 400, 500, etc.) est un CATÉGORIE. Vous pouvez à "affiner" le code d'erreur en choisissant une erreur spécifique au sein de la "catégorie".

À votre question de départ:
- Si le demande du Client est "mauvais" (par exemple, illégale nom d'utilisateur/mot de passe), puis revenir à une 4xx.
- Si le Serveur en quelque sorte échoue (par exemple, vous ne pouvez pas lire la base de données), puis revenir à un 5xx.
La "officielle" de la liste des codes d'erreur HTTP est le RFC 7231:

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

OriginalL'auteur paulsm4
1

Cela dépend de ce message que vous essayez de transmettre. Penser le code de statut afin d'orienter l'appelant sur la marche à suivre. Si c'est une erreur interne du serveur que l'utilisateur est peu probable d'être en mesure de faire quelque chose, cinq cents erreur est approprié.

Le serveur a rencontré une condition inattendue qui l'a empêché de satisfaire la requête.

D'autre part, un 409 indique un conflit que l'utilisateur pourrait théoriquement résoudre:

La demande n'a pas pu être terminé en raison d'un conflit avec l'état actuel de la ressource cible. Ce code est utilisé dans les situations où l'utilisateur peut être en mesure de résoudre le conflit et de soumettre à nouveau la demande.

Plus de 400 erreurs de niveau indiquent que l'utilisateur pourrait, en théorie, les corriger et resoumettre.

Personnellement, je vous conseille de les attraper, plus exactement, d'exceptions et de déterminer le statut de chaque code doit retourner, parce que cela dépend vraiment de votre cas d'utilisation. A partir de maintenant, vous êtes à la capture de Exception, et qui pourrait être à peu près tout donc c'est difficile de dire quel genre de conseils que vous devriez donner à l'appelant.

OriginalL'auteur Todd
1

5.XX code d'erreur côté serveur et 4.XXX codes d'erreur moyenne du côté client.

Ici vous attrapez toute exception :
```
 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);
}
```
Donc il est clairement impossible de savoir si le problème venait de la demande du client (mauvais paramètre par exemple) ou à partir d'un serveur erreur (incohérence dans la DB ou erreur de programmation par exemple).

Pour être en mesure de définir avec précision 4.XXX ou 5.XXX, votre code pourrait s'appuyer sur un certain nombre de base des exceptions comme ClientErrorException et ServerErrorException.

Jeter l'un ou l'autre, selon la cause d'erreur et vous pourriez alors compter sur eux pour définir le bon état code :
```
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);
}
```
Une autre façon serait d'ajouter le code d'état du champ à l'exception de la classe de base.

Vous pouvez donc tout simplement écrire :
```
try {
    studioService.createStudio(studioDto);
    response.setMessage("The studio was create");
    response.setStatusCode(HttpServletResponse.SC_CREATED);

} 
 catch (MyRestException e) {
    response.setStatusCode(e.getStatusCode());
}
```
Les exceptions susceptibles d'être jeté directement à partir de votre code que vous le détecter une erreur dans la demande du client (4.XXX).

De cette façon, vous pourriez envisager toutes les autres exceptions comme liés au traitement du serveur (5.XXX).

Un Printemps Gestionnaire d'Exception pourrait facilement effectuer cette tâche.

OriginalL'auteur davidxxx

Vous devez vous connecter pour publier un commentaire.