200
Ugh ... (309, 400, 403, 409, 415, 422) ... beaucoup de réponses essayant de deviner, argumenter et standardiser quel est le meilleur code retour pour une requête HTTP réussie mais un appel REST ayant échoué .
C'est mal de mélanger les codes d'état HTTP et les codes d'état REST.
Cependant, j'ai vu de nombreuses implémentations les mélanger, et de nombreux développeurs peuvent ne pas être d'accord avec moi.
Les codes de retour HTTP sont liés à HTTP Request
lui - même. Un appel REST est effectué à l'aide d'une demande de protocole de transfert hypertexte et il fonctionne à un niveau inférieur à la méthode REST invoquée elle-même. REST est un concept / approche, et sa sortie est un résultat métier / logique , tandis que le code de résultat HTTP est un transport .
Par exemple, retourner "404 Not found" lorsque vous appelez / users / est confus, car cela peut signifier:
- L'URI est incorrect (HTTP)
- Aucun utilisateur trouvé (REST)
"403 Interdit / Accès refusé" peut signifier:
- Autorisation spéciale nécessaire. Les navigateurs peuvent le gérer en demandant à l'utilisateur / mot de passe. (HTTP)
- Autorisations d'accès incorrectes configurées sur le serveur. (HTTP)
- Vous devez être authentifié (REST)
Et la liste peut continuer avec '500 Server error "(une erreur HTTP Apache / Nginx lancée ou une erreur de contrainte métier dans REST) ou d'autres erreurs HTTP, etc.
À partir du code, il est difficile de comprendre quelle était la raison de l'échec, un échec HTTP (transport) ou un échec REST (logique).
Si la requête HTTP a été exécutée physiquement avec succès, elle doit toujours renvoyer 200 codes, quel que soit le ou les enregistrements trouvés ou non. Parce que la ressource URI est trouvée et a été gérée par le serveur HTTP. Oui, il peut renvoyer un ensemble vide. Est-il possible de recevoir une page Web vide avec 200 comme résultat HTTP, non?
Au lieu de cela, vous pouvez retourner 200 codes HTTP avec quelques options:
- objet "erreur" dans le résultat JSON en cas de problème
- Tableau / objet JSON vide si aucun enregistrement trouvé
- Un indicateur de résultat / succès booléen en combinaison avec les options précédentes pour une meilleure manipulation.
De plus, certains fournisseurs d'accès Internet peuvent intercepter vos demandes et vous renvoyer un code HTTP 404. Cela ne signifie pas que vos données ne sont pas trouvées, mais c'est quelque chose de mal au niveau du transport.
De Wiki :
En juillet 2004, le fournisseur britannique de télécommunications BT Group a déployé le système de blocage de contenu Cleanfeed, qui renvoie une erreur 404 à toute demande de contenu identifié comme potentiellement illégal par Internet Watch Foundation. D'autres FAI renvoient une erreur HTTP 403 "interdite" dans les mêmes circonstances. La pratique consistant à utiliser de fausses erreurs 404 comme moyen de dissimuler la censure a également été signalée en Thaïlande et en Tunisie. En Tunisie, où la censure était sévère avant la révolution de 2011, les gens ont pris conscience de la nature des fausses erreurs 404 et ont créé un personnage imaginaire nommé "Ammar 404" qui représente "la censure invisible".
Pourquoi ne pas simplement répondre avec quelque chose comme ça?
{
"result": false,
"error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}
Google renvoie toujours 200 comme code d'état dans son API de géocodage, même si la demande échoue logiquement: https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes
Facebook renvoie toujours 200 pour les demandes HTTP réussies, même si la demande REST échoue: https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling
C'est simple, les codes d'état HTTP sont pour les requêtes HTTP. L'API REST vous appartient, définissez vos codes d'état.