Mettre un message d’erreur REST détaillé dans l’en-tête HTTP Warning, bonne / mauvaise idée?

Nous développons un service REST standard utilisant les codes d’état HTTP comme code de réponse si quelque chose ne va pas. (par exemple, une entrée utilisateur invalide renverrait “400 Bad Request” au client)

Cependant, nous avons estimé qu’un message d’erreur plus détaillé serait utile pour le client. (par exemple, l’erreur de saisie non valide est due au fait que X est un nom de paramètre non reconnu)

Nous aimerions être aussi fidèles aux spécifications HTTP que possible, donc après avoir étudié la spécification dans la RFC2616 , nous envisageons de mettre le message d’erreur détaillé dans les en-têtes HTTP, en particulier dans le champ d’avertissement d’en-tête HTTP . Il a déclaré sur le RFC que:

Le champ d’en-tête général d’avertissement est utilisé pour transporter des informations supplémentaires sur l’état ou la transformation d’un message, qui peuvent ne pas être reflétés dans le message . Ces informations sont généralement utilisées pour avertir d’un éventuel manque de transparence sémantique des opérations de mise en cache ou des transformations appliquées au corps d’entité du message.

Il ne semble y avoir aucune ressortingction à 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 conformément à l’intention initiale de cet en-tête. Nous aimons la sémantique et nous avons prévu d’utiliser le code d’avertissement 299, qui semble convenir parfaitement à la loi:

299 Avertissement persistant divers Le texte d’avertissement PEUT inclure des informations arbitraires à présenter à un utilisateur humain, ou consignées . Un système recevant cet avertissement NE DOIT PAS prendre d’action automatique.

Donc, compte tenu du 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 / pratique? Nous avons également constaté que certains services détaillaient ce message dans l’en-tête X-Warning, mais cela ne semble pas être standard. Nous nous demandons quelle serait la sagesse de la hive de la foule de REST stackoverflow à ce sujet. Existe-t-il également une pratique meilleure / standardisée pour la diffusion de messages d’erreur détaillés dans les réponses REST?

Pourquoi ne pas simplement changer la phrase de raison? C’est pour ça que c’est là. Le texte “Mauvaise demande” est uniquement 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 DEVRIEZ inclure un corps de réponse avec les détails d’une erreur.


METTRE À JOUR

Sur la base d’une lecture plus récente de la RFC 7231 et de matériel connexe, il semble que la seule raison valable de modifier l’expression de la raison soit de localiser le texte, et non de donner une signification plus spécifique. Désolé pour ça.

Où que vous placiez vos commentaires, que ce soit dans le corps du message (contenu) ou dans un en-tête Avertissement, veillez à ne pas donner d’informations susceptibles d’aider un attaquant à effectuer des tests de pénétration sur votre système.

Parfois, moins d’informations sont meilleures.

Je suis en faveur de l’utilisation des en-têtes pour l’avertissement uniquement lorsque la demande réussit en général.

Par exemple, un service qui obtient les détails d’un utilisateur, mais certains détails proviennent d’un tiers qui tombe souvent en panne. Dans notre cas, il était approprié de laisser cette section des données utilisateur vide, mais de signaler à l’utilisateur que certaines données sont manquantes.

La requête a donc renvoyé un message 200 Success avec une charge utile contenant tout ce que nous pouvions récupérer, mais contenant des en-têtes d’avertissement décrivant l’erreur pour le rest.

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 services, peut-être dans un fuseau horaire différent, etc. Peut-être même une société différente. Il ne sert à rien de retourner une réponse “non c’est une mauvaise demande”, comment le client peut-il résoudre le problème?

Donc, sur le plan philosophique: dites au client ce qu’il a la responsabilité de réparer. Les erreurs qui sont purement de la scope du serveur (par exemple, une erreur de connexion à la firebase database ou un problème logique), il est juste de renvoyer une erreur 500. Et ici, je ne renverrais aucun détail, nous ne voulons pas exposer les détails de notre implémentation interne au client.

Jusqu’à présent, je renvoyais 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 en fait être une approche plus propre.

Si cette proposition est acceptée, elle présente une alternative pour l’envoi de messages d’erreur détaillés. [ http://tools.ietf.org/html/draft-nottingham-http-browser-hints ]

Bien que ce soit un identifiant, il est relativement stable ces derniers temps, et je ne vois aucun problème à créer votre propre implémentation. (J’ai fait.)

429 Trop de demandes (RFC 6585) L’utilisateur a envoyé trop de demandes dans un délai donné. Destiné à être utilisé avec des schémas de limitation de débit.

Étant donné que vous autorisez une demande par durée de vie, vous implémentez un schéma de limitation de débit. Il s’agit donc de la réponse HTTP appropriée.

Vous pouvez également (et est encouragé par la spécification HTTP) de personnaliser le corps de la réponse HTTP, de sorte que vous puissiez remplacer “Trop de demandes” par une explication de votre choix.