Quand est-il approprié de répondre avec un HTTP 412 erreur?

Il est clair pour moi quand vous devriez et ne devrait pas retourner une HTTP 412: Échec de la Condition préalable, d'erreur pour un service web? Je pense à l'utiliser lors de la validation de données. Par exemple, si un client de la POSTE de données XML et des données est obligatoire manquante dans un élément de données, puis de répondre avec un 412 et une description de l'erreur.

Ne fait que s'aligner avec l'esprit de répondre avec un HTTP 412, ou quelque chose d'autre (par exemple, un autre code d'erreur http ou de l'application web exception)?

InformationsquelleAutor TERACytE | 2011-03-20
  1. 53

    Si vous regardez La RFC 2616 vous verrez un certain nombre d'en-têtes de requête qui peut être utilisé pour appliquer des conditions à une demande:

    If-Match
If-Modified-Since
If-None-Match
If-Range
If-Unmodified-Since

    Ces en-têtes contiennent des "conditions préalables", permettant au client de dire au serveur de ne remplir la demande si certaines conditions sont remplies. Par exemple, vous utilisez un PUT demande de mettre à jour l'état d'une ressource, mais vous voulez seulement le PUT être mise en oeuvre si la ressource n'a pas été modifié par quelqu'un d'autre depuis votre plus récente GET.

    Le code d'état de réponse 412 (Échec de la Condition préalable) est généralement utilisé lorsque ces conditions préalables à l'échec.

    Votre exemple, sonne comme une demande non valide (par exemple, le client a soumis des données est invalide en raison de valeurs manquantes). Un code d'état de 400 (Bad Request) est plus approprié ici IMO.

    InformationsquelleAutor joelittlejohn
  2. 10

    412 est réservée aux cas où la demande est conditionnelle, et la condition n'est pas remplie.

    Pour votre cas d'utilisation, 422 Unprocessable Entité est un bon match.

    • Il convient de mentionner que le code d'état 422 ne fait pas partie de la RFC 2616. Il fait partie d'une extension de HTTP 1.1 pour WebDAV.
    • joelittlejohn: pourquoi est-ce un problème? Codes d'état sont un point d'extension dans la RFC 2616, et c'est une extension très utile.
    • Je ne veux pas laisser entendre que c'est un problème, mais seulement qu'il vaut la peine de mentionner 🙂
    • Je l'aime ainsi. Il distingue clairement les demandes rejetées pour des affaires de validation des raisons de ceux rejetés en raison de conditions temporaires ou des bogues logiciels. Ces trois classes d'erreur doivent être très différemment.
    InformationsquelleAutor Julian Reschke
  3. 8

    Votre meilleur pari serait d'éviter de 412. Dans la pratique, la plupart des services web que j'ai utilisé envoyer un 400 code (Bad Request). Beaucoup de cadres ont en charge intégrée de 400 trop et vos clients apprécieront un plus commune erreur de code. Souvent, surtout avec des interfaces REST, un simple "message" ou "erreur" élément est retourné avec une description.

    • Les Clients sont censés traiter avec n'importe quel inconnu code 4xx 400 de toute façon.
    • Ce sujet 404?
    • 404 ne serait pas un code inconnu. Que l'on doit probablement être traités au cours de toute 400-499 codes qui ne sont pas explicitement traitées doivent être traités comme un générique de 400.
    • 404 ressource est introuvable. 412 est une condition préalable a échoué, ce qui semble vague. Est-ce la raison pourquoi nous préférons traiter toutes les réponses vagues 400 ? Ou est-ce autre chose ?
    InformationsquelleAutor Matt Bishop