Gestion des exceptions backend pour l'application REST - devrions-nous retourner l'erreur 4XX ou 200 avec la marque d'erreur

Question

Je travaille sur une application web à grande échelle, et dans le projet je développe une application REST pour les clients externes. Je pense que cette question n'a pas grand chose à voir avec la technologie spécifique que j'utilise, mais juste au cas où - c'est Django.

Nous avons une convention avec l'équipe de développement qui REPOS les ressources retournent toujours un objet standard JSON de type

{'success': <value>, 
'object': <value> 
'error_msg': <value>, 
} 

ainsi que l'état (200, 201, 403, etc ....)

Exemples de mise en œuvre de Django:

return Response({'success': true, 
       'object': ..., 
       'error_msg': ...}, 
       status=status.HTTP_200_OK) 

le paramètre success est affecté true pour un déploiement réussi de la ressource, et false sinon.

Maintenant, la question entière se trouve ici dans ce qui devrait être passé dans status paramètre dans les cas où quelque chose de mal se passe - code 4XX approprié ou 200 ?. L'équipe de développement suggère de TOUJOURS utiliser HTTP_200_OK, simplement si quelque chose de mal s'est passé, il suffit d'attribuer la valeur false à success. Le error_msg contiendra un message d'erreur détaillé en cas d'exception.

Ainsi, les deux alternatives parmi lesquelles je ne peux pas choisir le bon regard comme celui-ci

return Response({'success': false, 
        'object': ..., 
        'error_msg': 'Details regarding the error'}, 
        status=status.HTTP_400_BAD_REQUEST) 

vs:

return Response({'success': false, 
       'object': ..., 
       'error_msg': 'Details regarding the error'}, 
       status=status.HTTP_200_OK) 

(dans les deux cas success sera égal à false Ainsi, dans les deux. cas le développeur saura que quelque chose s'est mal passé en regardant success sans avoir à vérifier status)
Cependant, l'existence même de différents error codes me laisse avec un doute désagréable qu'il me manque quelque chose sur pourquoi les gens ont mis au point différents codes d'erreur. Et dans quelles situations mon projet peut rencontrer des problèmes s'il renvoie toujours le même code d'état. Après avoir lu des tonnes de matériaux, je n'ai aucune explication matérielle pourquoi spécifier des codes d'état d'erreur appropriés pourrait surpasser l'approche de retour 200 statut.

Answer 1

codes HTTP sont à mon avis un excellent moyen d'obtenir des informations sur le résultat d'une opération pour les raisons suivantes:

• Ils sont à la fois machine et lisible par l'homme (au moins par les développeurs).
• Ils sont intégrés dans toutes les transactions HTTP, de sorte que chaque bibliothèque implémente des mécanismes pour les traiter.
• Le répertoire des codes d'erreur est «standardisé» et tout le monde sait comment y faire face, et il couvre de nombreux cas courants (le framework DRF en utilise automatiquement certains, comme 400, 403 ou 405). En les ignorant, vous augmentez la quantité de travail que vous devez implémenter par vous-même.

Bien sûr, ils pourraient ne pas suffire pour des cas particuliers. Supposons que vous receviez un code 400 lorsque vous envoyez plusieurs champs à votre API.Si vous voulez savoir lesquels sont invalides et pourquoi, vous avez toujours besoin de la valeur de votre error_msg, mais le code 400 simplifie encore beaucoup votre logique, puisque vous pouvez filtrer beaucoup d'autres raisons pour lesquelles la requête n'a pas abouti (403, 405 ...).

En ce qui concerne votre question:

et dans quel SITUATIONS mon projet peut faire face à des difficultés si elle retourne toujours le même 200

Eh bien, si vous implémentez les choses correctement, laissant toute erreur de manipulation au date de réponse, cela ne devrait jamais causer de problème, mais comme je l'ai déjà dit, j'ai l'impression que cela augmente la complexité de la tâche à accomplir.

S'il vous plaît noter que ce ne sont que mes deux cents, et il pourrait y avoir d'autres opinions avec de meilleurs arguments pour le cas contraire.