web-dev-qa-db-fra.com

Renvoyer http 200 OK avec une erreur dans le corps de la réponse

Je me demande s'il est correct de renvoyer HTTP 200 OK lorsqu'une erreur côté serveur s'est produite avec une erreur à l'intérieur du corps de la réponse.

Exemple:

  1. Nous envoyons http GET
  2. Quelque chose d'inattendu s'est produit côté serveur.
  3. Le serveur renvoie le code d'état http 200 OK avec une erreur dans une réponse (par exemple, {"status":"some error occured"}

Est-ce que le comportement est correct ou pas? Ne devrions-nous pas changer le code d'état? 

48
krzakov

Non, c'est très incorrect.

HTTP est un protocole d'application. 200 implique que la réponse contient une charge utile qui représente le statut de la ressource demandée. Un message d'erreur n'est généralement pas une représentation de cette ressource.

En cas de problème lors du traitement de GET, le code d’état correct est 4xx ("vous vous êtes trompé") ou 5xx ("Je me suis trompé").

67
Julian Reschke

Les codes d'état HTTP disent quelque chose sur le protocole HTTP. HTTP 200 signifie que la transmission est correcte sur le niveau HTTP (c'est-à-dire que la demande était correcte sur le plan technique et que le serveur était en mesure de répondre correctement). Voir cette page wiki pour une liste de tous les codes et de leur signification. 

HTTP 200 n'a rien à voir avec le succès ou l'échec de votre "code d'entreprise". Dans votre exemple, HTTP 200 est un statut acceptable pour indiquer que votre "message d'erreur de code métier" a été transféré avec succès, à condition qu'aucun problème technique n'ait empêché la logique métier de s'exécuter correctement.

Vous pouvez également laisser votre serveur répondre avec HTTP 5xx si des problèmes techniques ou irrécupérables se produisent sur le serveur. Ou HTTP 4xx si la requête entrante présente des problèmes (paramètres incorrects, méthode HTTP inattendue, etc.). Ils indiquent tous une nouvelle erreur technique alors que HTTP 200 indique une erreur technique NO ne donne aucune garantie concernant les erreurs de logique métier.

Pour résumer: OUI, il est valide d’envoyer des messages d’erreur (pour les problèmes non techniques) dans votre réponse http avec le statut HTTP 200. Vous êtes libre de choisir si cela s’applique à votre cas. Si, par exemple, le client demande un fichier qui n’y est pas, ce serait plutôt un 404. S'il existe une mauvaise configuration sur le serveur qui pourrait être un 500. Si le client demande une place dans un avion réservé, il s'agira de 200 et votre "implémentation" dictera comment le reconnaître/le gérer (par exemple, un bloc JSON avec un { "booking","failed" }).

17
geert3

Même si je veux renvoyer une erreur de logique métier sous forme de code HTTP, il n'existe pas de code d'erreur HTTP acceptable pour cette erreur plutôt que d'utiliser HTTP 200, car il induirait en erreur l'erreur réelle.

Ainsi, HTTP 200 sera utile pour les erreurs de logique métier. Mais toutes les erreurs couvertes par les codes d'erreur HTTP doivent les utiliser.

En gros, HTTP 200 signifie que le serveur traite correctement la demande de l'utilisateur (en cas d'absence de sièges dans l'avion, peu importe, car la demande de l'utilisateur a été correctement traitée, elle peut même renvoyer un nombre de sièges disponibles dans l'avion. aucune erreur de logique métier ni cette logique pouvant être du côté client. L'erreur logique est un sens abstrait, mais l'erreur HTTP est plus précise).

7
Alexanderius

HTTP Le protocole gère-t-il la transmission de données sur Internet? 

Si cette transmission est interrompue pour une raison quelconque, les codes d'erreur HTTP vous expliquent pourquoi cette transmission ne peut pas vous être envoyée. 

Les données en cours de transmission ne sont pas gérées par les codes d'erreur HTTP. Seul le mode de transmission. 

HTTP ne peut pas dire "Ok, cette réponse est gobbledigook, mais la voici". il dit simplement 200 OK

i.e: J'ai terminé mon travail de vous le faire parvenir, le reste est à vous.

Je sais que cela a déjà été répondu, mais je le résume avec des mots que je peux comprendre. désolé pour toute répétition.

1
Chris Groves