Retour de http 200 OK avec erreur dans le corps de réponse

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

Exemple:

  1. Nous envoyons http GET
  2. quelque Chose d'inattendu s'est produit sur le côté serveur.
  3. retour du serveur http 200 OK Code d'état avec erreur à l'intérieur d'une réponse (par exemple {"status":"some error occured"}

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

41
demandé sur CodeCaster 2015-01-13 14:53:29

5 réponses

Non, c'est très incorrect.

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

si quelque chose tourne mal pendant le traitement GET, le bon code d'état est 4xx ("vous avez foiré") ou 5xx ("j'ai foiré").

61
répondu Julian Reschke 2015-01-13 13:05:33

les codes de statut HTTP disent quelque chose à propos du protocole HTTP. HTTP 200 signifie que la transmission est correcte au niveau HTTP(I. la requête était techniquement correcte et le serveur était capable de répondre correctement). Voir cette page wiki pour une liste de tous les codes et leur signification.

HTTP 200 n'a rien à voir avec le succès ou l'échec de votre "business code". Dans votre exemple, le HTTP 200 est un statut acceptable pour indiquer que votre "message d'erreur du code d'entreprise" a été transfert, à condition qu'aucun problème technique n'empêche la logique commerciale de fonctionner correctement.

vous pouvez aussi laisser votre serveur répondre avec HTTP 5xx si des problèmes techniques ou irrécupérables se sont produits sur le serveur. Ou HTTP 4xx si la requête entrante avait des problèmes (par exemple mauvais paramètres, méthode HTTP inattendue)... De nouveau, ces indiquent tous technique erreurs, tandis que HTTP 200 indique NO erreurs techniques, mais ne garantit pas erreurs de logique opérationnelle.

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. Si cela s'applique à votre cas, à vous de voir. Si, par exemple, le client demande un fichier qui n'est pas là, ce serait plus comme un 404. S'il y a une mauvaise configuration sur le serveur qui pourrait être un 500. Si le client demande un siège dans un avion complet, ce sera 200 et votre la" mise en œuvre " dictera comment reconnaître/gérer ceci (par exemple un bloc JSON avec un { "booking","failed" })

12
répondu geert3 2015-01-14 09:53:07

même si je veux retourner une erreur de logique d'entreprise en tant que Code HTTP, il n'y en a pas code D'erreur HTTP acceptable pour ces erreurs plutôt que D'utiliser HTTP 200 parce qu'il va donner une fausse image de l'erreur réelle.

ainsi, HTTP 200 sera bon pour les erreurs de logique métier. Mais toutes les erreurs qui sont couvertes par les codes D'erreur HTTP doivent les utiliser.

fondamentalement HTTP 200 signifie ce que le serveur traite correctement la requête de l'utilisateur (dans le cas où il n'y a pas de sièges sur le plan, il n'est pas question parce que demande de l'Utilisateur a été correctement traitée, il peut même retourner juste un certain nombre de sièges disponibles sur le plan, de sorte qu'il n'y aura pas d'erreurs de logique d'affaires du tout ou que la logique d'affaires peut être du côté du client. L'erreur de logique d'entreprise est une signification abstraite, mais L'erreur HTTP est plus définie).

7
répondu Alexanderius 2015-08-12 07:07:11

pour clarifier, vous devriez utiliser les codes D'erreur HTTP où ils correspondent au protocole, et ne pas utiliser les codes de statut HTTP pour envoyer logique erreurs.

des erreurs comme solde insuffisant,pas de cabines disponibles,mauvaise utilisateur/mot de passe qualifiez-vous pour le statut HTTP 200 avec traitement des erreurs spécifiques à l'application dans le corps de réponse.

Voir ce logiciel d'ingénierie réponse:

je dirais qu'il est préférable d'être explicite sur la séparation des protocoles. Laissez le serveur HTTP et le navigateur Web faire leur propre chose, et laissez l'application faire ses propre chose. L'application doit être capable de faire des requêtes, et elle a besoin des réponses--et sa logique quant à la façon de demander, comment interpréter les réponses, peut être plus (ou moins) complexe que la perspective HTTP.

2
répondu vedant 2018-07-11 07:58:39

HTTP est le protocole qui traite la transmission de données sur internet.

si cette transmission est interrompue pour quelque raison que ce soit, les codes D'erreur HTTP vous indiquent pourquoi elle ne peut pas vous être envoyée.

les données transmises ne sont pas traitées par des codes D'erreur HTTP. Seulement 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 l'apporter, le reste est à vous.

je sais que cela a déjà été répondu mais je l'ai mis dans des mots que je peux comprendre. désolé pour la répétition.

0
répondu Chris Groves 2018-09-10 15:14:39