Salut,
pour ma part (quand bien même me traiterait-on de psycho-rigide), je pense qu'il faut toujours setter les code de retour HTTP, car ce sont eux qui, selon le standard web, définissent ce que "représente" la page (aka "est ce que ma commande a bien marché? si elle a foiré pourquoi?").
Mettre le bon statut permettra alors de gérer correctement ces erreurs dans le code client, et d'être compris par les autres clients (moteur de recherche, autres développeurs utilisant ton API, etc).
Par exemple, si tu retournes un code 200 au lieu du 404, et que tu écris dans la page "Page non trouvée, 404", alors pour google (ou tout autre moteur de recherche), ce sera une page valide: elle sera indexée, t'auras 0 retour de la part du moteur (ou d'autre système) pour te dire "cette page a fichu le camp!" et tu pourrais même être pénalisé pour "duplicated content" (= cette fausse page 404 revient souvent, donc ton site a beaucoup de pages en doublon, donc tu essaies peut-être de blouzer le moteur de recherche).
Pour les navigateurs, cela pourrait également être important: cela permet au navigateur de savoir s'il peut/devrait recharger la page (si on répond un "temporarily not available", peut-être que le navigateur va recharger la page au bout de 1 minute, ou qu'un plugin le fera).
Pour tes outils de stats, c'est aussi important: dans les stats Urchin d'OVH, tu as le nb de codes 5xx et 4xx, pour savoir si tu as des erreurs ou non. Idem dans les log Apache.
Donc, oui, c'est important de retourner les bons status HTTP, ça (te) sera toujours utile un jour. Et il en existe des brouettes, donc tu as surement déjà le code qui matche ton erreur (rien n'interdit d'en rajouter 1 ou 2 custom si besoin).
PS: en pièce jointe, je t'ai mis les enums dont je me sert pours les codes http, et les headers de requete/réponse (puis quelques enums de plus)
pour ma part (quand bien même me traiterait-on de psycho-rigide), je pense qu'il faut toujours setter les code de retour HTTP, car ce sont eux qui, selon le standard web, définissent ce que "représente" la page (aka "est ce que ma commande a bien marché? si elle a foiré pourquoi?").
Mettre le bon statut permettra alors de gérer correctement ces erreurs dans le code client, et d'être compris par les autres clients (moteur de recherche, autres développeurs utilisant ton API, etc).
Par exemple, si tu retournes un code 200 au lieu du 404, et que tu écris dans la page "Page non trouvée, 404", alors pour google (ou tout autre moteur de recherche), ce sera une page valide: elle sera indexée, t'auras 0 retour de la part du moteur (ou d'autre système) pour te dire "cette page a fichu le camp!" et tu pourrais même être pénalisé pour "duplicated content" (= cette fausse page 404 revient souvent, donc ton site a beaucoup de pages en doublon, donc tu essaies peut-être de blouzer le moteur de recherche).
Pour les navigateurs, cela pourrait également être important: cela permet au navigateur de savoir s'il peut/devrait recharger la page (si on répond un "temporarily not available", peut-être que le navigateur va recharger la page au bout de 1 minute, ou qu'un plugin le fera).
Pour tes outils de stats, c'est aussi important: dans les stats Urchin d'OVH, tu as le nb de codes 5xx et 4xx, pour savoir si tu as des erreurs ou non. Idem dans les log Apache.
Donc, oui, c'est important de retourner les bons status HTTP, ça (te) sera toujours utile un jour. Et il en existe des brouettes, donc tu as surement déjà le code qui matche ton erreur (rien n'interdit d'en rajouter 1 ou 2 custom si besoin).
PS: en pièce jointe, je t'ai mis les enums dont je me sert pours les codes http, et les headers de requete/réponse (puis quelques enums de plus)