Mettre un message D'erreur REST détaillé dans L'en-tête D'avertissement HTTP, Bonne/Mauvaise idée?
nous développons un service de repos standard utilisant les codes de statut HTTP comme code de réponse en cas de problème. (par exemple, un utilisateur non valide retournerait "400 Bad Request" au client)
Toutefois, nous avons estimé qu'un message d'erreur plus détaillé serait utile pour le client. (par exemple, l'erreur de saisie invalide est due au fait que X est un nom de paramètre non reconnu)
nous aimerions être aussi fidèles que possible aux spécifications HTTP, donc après avoir étudié les spécifications RFC2616, nous pensons mettre le message d'erreur détaillé dans les en-têtes HTTP, spécifiquement sur le champ d'avertissement de l'en-tête HTTP. Il a dit sur la RFC:
le champ Warning general-header est utilisé pour transportent des informations supplémentaires sur le statut ou la transformation d'un message qui pourraient ne pas être reflétées dans le message. Cette information est généralement utilisé pour avertir d'un éventuel manque de transparence sémantique de opérations de mise en cache ou transformations appliquées au corps de l'entité du message.
il ne semble y avoir aucune restriction sur l'utilisation de cet en-tête pour d'autres avertissements (tels que le message D'erreur REST), même ceux qui ne sont pas liés aux avertissements de cache selon l'intention originale de cet en-tête. Nous aimons la sémantique, et nous avons prévu d'utiliser le code d'avertissement 299, qui semble correspondre assez bien à la facture:
299 Divers avertissement persistant l'avertissement le texte peut inclure des informations arbitraires pour être présentés à un utilisateur humain, ou connecté. Un système recevant cet avertissement ne doit pas prendre de mesures automatisées.
donc, étant donné le cas d'erreur de saisie invalide présenté en haut de cette question, nous pensons mettre notre message D'erreur REST comme l'exemple suivant:
HTTP/1.1 400 Bad Request
Warning: 299 ServiceName "Invalid input error: X is unrecognized parameter name."
Est-ce une bonne idée ou pratique? Nous avons également constaté que certains services détaillaient ce message dans l'en-tête X-Warning, mais cela semble pour ne pas être standard. Nous nous demandons ce que la sagesse ruche de stackoverflow reste foule pense à ce sujet. Existe-t-il également une pratique meilleure ou normalisée pour transmettre des messages d'erreur détaillés dans les réponses REST?
6 réponses
pourquoi ne pas simplement changer la phrase de raison? C'est ce qu'il est là pour ça. Le texte" Bad Request " n'est que le texte par défaut. Si vous souhaitez inclure plus d'informations, utilisez le corps de réponse. La spécification HTTP indique que vous devez inclure un corps de réponse avec les détails d'une erreur.
UPDATE
D'après une lecture plus récente de la RFC 7231 et de documents connexes, Il semble que la seule raison valable pour changer la phrase de raison est de localiser le texte, et non de fournir un sens plus précis. Désolé à ce sujet.
partout où vous mettez vos commentaires, que ce soit dans le corps du message (contenu) ou dans un en-tête D'avertissement, faites attention à ne pas donner d'informations qui pourraient être utiles à un attaquant faisant des tests de pénétration sur votre système.
parfois moins d'info est mieux.
je suis en faveur d'utiliser des en-têtes pour avertir seulement quand la requête réussit en général.
par exemple, un service qui reçoit les détails d'un utilisateur, mais certains des détails proviennent d'un tiers qui descend souvent. Dans notre cas, il était préférable de laisser cette section de l'utilisateur de données vide, mais afficher un avertissement à l'utilisateur que certaines données sont manquantes.
ainsi la demande a rapporté un succès de 200 avec une charge utile qui contenait tout ce que nous pouvions récupérer, mais alors avait en-têtes d'avertissement qui décrivaient l'erreur pour le reste.
je suis en faveur de l'approche générale. Nous devrions supposer que le développeur client est dans une équipe différente du développeur de service, peut-être dans un fuseau horaire différent, etc. Peut-être même d'une société différente. Il n'est pas bon de simplement retourner une réponse "non c'est une mauvaise demande", comment le client peut-il résoudre le problème.
d'un point de vue philosophique: parlez au client des choses qu'il a la responsabilité de corriger. Les erreurs qui sont purement la portée du serveur (par ex. connexion de base de données erreur, ou un problème logique) il est juste de retourner une erreur 500. Et ici, Je ne veux pas renvoyer de détails, nous ne voulons pas exposer les détails de notre implémentation interne au client.
Jusqu'à présent j'ai retourné des données dans le corps de la réponse, en utilisant JAX/RS:
return Response.status(400).entity("some message here").build();
je pense que votre utilisation des en-têtes peut être en fait une évaluation plus propre.
Si cette proposition est accepté, il présente une alternative pour l'envoi de messages d'erreur de détail. [http://tools.ietf.org/html/draft-nottingham-http-browser-hints]
bien que ce soit un I-D, c'est assez stable ces derniers temps, et je ne vois aucun problème à construire votre propre implémentation. (Je l'ai fait.)
429 demandes trop nombreuses (RFC 6585) L'Utilisateur a envoyé trop de requêtes dans un laps de temps donné. Destiné à être utilisé avec des systèmes de limitation des taux.
puisque vous autorisez une requête par durée de vie, vous mettez en place un schéma de limitation de vitesse, c'est donc la réponse HTTP appropriée.
vous pouvez aussi (et êtes encouragé par la spécification HTTP) personnaliser le corps de réponse HTTP, de sorte que vous pouvez modifier "Too Many Requests" à n'importe quelle explication que vous voulez.