J'ai récemment rejoint un nouveau projet. Dans ce projet, toutes les API en service renvoient toujours le code d'état 200. Même si cette réponse devait être 400 ou 404, l'API renvoie le code d'état 200.
J'ai demandé la raison pour laquelle les API ne renvoient pas d'autres codes de réponse, et les programmeurs m'ont dit qu'ils n'utilisaient pas de code de réponse. ils mettent des informations dans le corps.
par exemple, il manque des champs obligatoires, ils renvoient le code d'état de réponse 200, mais le corps renvoie comme ceci
{"result" : "unautherized"}
si un utilisateur non autorisé essaie pour y accéder, le code de statut est 200, le corps retourne comme ça
{"result" : "fail"}
ce que j'ai fait avant était très différent, j'ai toujours spécifié le code de statut par cas et j'essaye de retourner un statut approprié code et message. Je pensais que c'était la partie du protocole HTTP. Cependant, ils m'ont dit que spécifier un code d'état comme 400, 404, 300 faisait partie de l'API RESTful, et renvoyer toujours 200 est le bon code d'état parce que le serveur a répondu et qu'il est actif. Les API doivent toujours renvoyer 200 sauf 500. Parce que lorsque le serveur meurt, il ne peut rien renvoyer.
Voici donc la question.
3 Réponses :
Le serveur doit toujours renvoyer le code d'état 200 sauf si le serveur meurt?
J'ai posé la même question sur le génie logiciel il y a quelques années: Les applications Web utilisent-elles HTTP comme couche de transport ou font-elles partie intégrante du serveur HTTP? . Voir aussi Dois-je utiliser les codes d'état HTTP pour décrire les événements au niveau de l'application .
La spécification de divers codes d'état fait partie de l'API REST?
Non, REST est indépendant du transport. Il peut être utilisé par-dessus HTTP, mais ce n'est pas nécessaire. Par conséquent, il ne dit rien sur les codes d'état.
Il est courant de ne pas utiliser de code d'état?
Cela dépend de la personne à qui vous demandez.
C'est une question de préférence. Je n'aime absolument pas les questions "Quel est le code d'état le plus approprié pour le scénario X?" . Il y a aussi:
Et bien d'autres. Je me souviens qu'il y avait un site proposant un organigramme pour déterminer le code de statut (le plus) approprié.
En général, ne vous inquiétez pas. La cohérence et une documentation complète sont plus importantes que l'attribution du numéro approprié.
C'est une bonne réponse et je ne comprends pas pourquoi il y a un vote négatif.
Ce que fait l'équipe peut être tout à fait approprié pour les circonstances dans lesquelles elle se trouve. Mais étiqueter ces modèles comme REST semble inexact.
Je dis cela, car il semble que l'équipe n'ait pas réfléchi à la façon dont son système de messagerie actuel fonctionne avec les participants génériques dans l'échange de messages.
Par exemple, la mise en cache est une préoccupation importante dans le style architectural REST. Dans HTTP, la RFC 7234 décrit la sémantique de la mise en cache. En particulier, il existe une section sur la manière dont l ' invalidation du cache est déclenchée par les codes d'état. Cela indique à son tour que, si vous ne faites pas la distinction entre les codes d'état dans les cas de réussite et d'échec, alors les composants génériques invalideront les entrées mises en cache qui ne devraient pas être invalidées.
J'ai rejoint un projet qui utilise exactement la même stratégie: intégrer un message d'état dans le corps de la réponse et laisser le code d'état toujours 200 . Pour des raisons de cohérence, il est préférable de suivre la stratégie existante pendant le temps de maintenance du logiciel. Cependant, il n'est pas recommandé pour tout nouveau projet, pour les raisons énumérées ci-dessous:
"Spécifier un code d'état comme 400, 404, 300" suit la conception RESTful, mais ne fait PAS partie de REST. En fait, utilisation de 302 (redirection), 401 (authentification de base et Digest), 404 (page par défaut introuvable sur le serveur Web), 500 (page d'erreur du serveur par défaut) est populaire il y a des décennies, bien avant l'API RESTful de nos jours (je sais que RESTful est proposé il y a des décennies, mais il n'est populaire que ces dernières années).
"Renvoyer toujours 200 est le bon code de statut car le serveur a répondu et il est actif" . Ceci est une erreur. Si c'est le cas, alors seul 200 peut être utilisé pour le code d'état - tant que le serveur est "actif", il peut renvoyer un message. 500 n'est pas non plus acceptable, car dans ce cas, le serveur est toujours "vivant", il ne meurt pas ... Ensuite, comme le code de statut doit toujours être 200 , pourquoi avons-nous besoin du code?
"Il est courant de ne pas utiliser de code d'état?" . En fait, c'est le contraire. Le schéma de conception d'API RESTful étant de plus en plus populaire, de plus en plus de projets utilisent le code d'état HTTP pour fournir la sémantique des messages. Mais de toute façon, c'est un point de vue basé sur l'opinion.