Code de réponse REST pour les données non valides


272

Quel code de réponse doit être transmis au client en cas de scénarios suivants?

  1. Des données non valides ont été transmises lors de l'inscription de l'utilisateur, comme un mauvais format de courrier électronique
  2. Le nom d'utilisateur / e-mail existe déjà

J'ai choisi 403. J'ai également trouvé que je pense que l'on peut l'utiliser.

Wikipédia:

412 Échec de la condition préalable: le serveur ne remplit pas l'une des conditions préalables que le demandeur a imposées à la demande

Suggérer le code si je dois utiliser autre que 403.



Je résous également ce problème. Le chapitre 7, Validation de la spécification JAX-RS (2017), fournit des conseils sur le code d'état spécifiquement pour les violations de contraintes. download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-spec/…
burntsugar

Réponses:


298

400 est le meilleur choix dans les deux cas. Si vous souhaitez clarifier davantage l'erreur, vous pouvez modifier la phrase de raison ou inclure un corps pour expliquer l'erreur.

412 - L'échec de la précondition est utilisé pour les demandes conditionnelles lors de l'utilisation de la date de dernière modification et des ETags.

403 - Interdit est utilisé lorsque le serveur souhaite empêcher l'accès à une ressource.

Le seul autre choix possible est 422 - Entité non traitable.


10
bien qu'il soit souvent utilisé dans ce contexte, 403 ne se limite pas au contrôle d'accès, car rfc2616-10.4.4 dit: "Le serveur a compris la demande, mais refuse de la satisfaire. [...] si le serveur souhaite faire public pourquoi la demande n'a pas été satisfaite, elle DEVRAIT décrire le motif du refus dans l'entité. " La raison peut être des données non valides. Cependant, 422 est plus applicable ici.
Yannick Loiseau

7
Ne nous laissons pas prendre par la critique textuelle. Voir par exemple trac.tools.ietf.org/wg/httpbis/trac/ticket/294 qui tente de clarifier que 403 est et a toujours été une autorisation.
fumanchu

2
@fumanchu Belle prise. Un lien vers une demande de changement qui n'a que 7 heures :-)
Darrel Miller

1
@fumanchu Cela signifie que 403 doit être renvoyé si l'utilisateur n'a pas la permission d'accéder à la ressource demandée. Mais je pense que 401 Unauthorized est plus approprié pour accéder aux ressources sur lesquelles l'utilisateur n'a pas d'autorisation.
Amit Patel

1
401 Unauthorized demandera à un navigateur Web d'afficher à l'utilisateur l'invite de nom d'utilisateur / mot de passe HTTP standard. Si vous n'utilisez pas ce type d'authentification pour votre service, ou si l'utilisateur dispose déjà d'une authentification HTTP, 401 n'est pas approprié.
Greg Ball

92

Je recommanderais 422. Il ne fait pas partie de la spécification HTTP principale, mais il est défini par une norme publique (WebDAV) et il devrait être traité par les navigateurs de la même manière que tout autre code d'état 4xx.

De RFC 4918 :

Le code d'état 422 (entité non traitable) signifie que le serveur comprend le type de contenu de l'entité de demande (donc un code d'état 415 (type de support non pris en charge) est inapproprié), et la syntaxe de l'entité de demande est correcte (donc 400 (mauvaise demande) ) le code d'état est inapproprié) mais n'a pas pu traiter les instructions contenues. Par exemple, cette condition d'erreur peut se produire si un corps de requête XML contient des instructions XML bien formées (c'est-à-dire syntaxiquement correctes) mais sémantiquement erronées.


20
Notez que le texte cité indique que 422 est applicable lorsque l'entité de demande est syntaxiquement bien formée, mais sémantiquement erronée. Si l'entité de demande est tronquée, 400 est la réponse appropriée.
Matty K

87

Si la requête n'a pas pu être correctement analysée (y compris l'entité / le corps de la requête), la réponse appropriée est 400 Bad Request [ 1 ].

La RFC 4918 indique que 422 entité non traitable est applicable lorsque l'entité de demande est syntaxiquement bien formée, mais sémantiquement erronée. Donc, si l'entité de requête est tronquée (comme un mauvais format de courrier électronique), utilisez 400; mais si cela n'a pas de sens (comme @example.com), utilisez 422.

Si le problème est que, comme indiqué dans la question, le nom d'utilisateur / e-mail existe déjà, vous pouvez utiliser 409 Conflict [ 2 ] avec une description du conflit et un indice sur la façon de le résoudre (dans ce cas, "choisissez un nom d'utilisateur / e-mail différent "). Cependant, dans la spécification écrite, 403 Forbidden [ 3 ] peut également être utilisé dans ce cas, malgré les arguments concernant l'autorisation HTTP.

412 Precondition Failed [ 4 ] est utilisé lorsqu'un en-tête de demande de précondition (par exemple If-Match) qui a été fourni par le client est évalué comme faux. Autrement dit, le client a demandé quelque chose et a fourni des conditions préalables, sachant très bien que ces conditions préalables pourraient échouer. 412 ne doit jamais être lancé sur le client à l'improviste et ne doit pas être lié à l'entité de demande en soi .


1
Je devrais noter les RFC HTTP / 1.1 mis à jour: 400 Bad Request, 409 Conflict, 403 Forbidden etc. live in tools.ietf.org/html/rfc7231 ; 412 La condition préalable a échoué se trouve dans tools.ietf.org/html/rfc7232#section-4.2
Matty K le

41

Il est amusant de revenir 418 I'm a teapotà des demandes qui sont manifestement conçues ou malveillantes et qui «ne peuvent pas arriver», comme l'échec de la vérification CSRF ou des propriétés de demande manquantes.

2.3.2 418 je suis une théière

Toute tentative de préparer du café avec une théière devrait entraîner le code d'erreur "418 I'm a teapot". Le corps d'entité résultant PEUT être court et robuste.

Pour le garder raisonnablement sérieux, je limite l'utilisation de codes d'erreur amusants aux points de terminaison RESTful qui ne sont pas directement exposés à l'utilisateur.


11
Implémentez-le de telle sorte que votre API revienne 418 I'm a teapotpour toutes les demandes provenant de votre patron :)
vikarjramun

2
@vikarjramun, j'ai construit un REST factice et rendu prudent hors ligne. (version préliminaire) maintenant, nos étudiants cherchent à créer des demandes de données valides, mais ce n'est que théière. Je suis le "patron" - mais ça marche aussi.
LenglBoy

2
Ce RFC est stupide. Vous pouvez faire du café dans une théière, tant que vous le versez à travers une passoire à thé dans votre tasse. Tout comme avec du thé en feuilles. Vous pouvez également faire du thé dans une cafetière sans problème.
gburton

2
@gburton Cela nécessite cependant l'intervention d'un humain. Sur le réseau, vous avez certainement besoin d'un appareil compatible avec le café pour faire du café. Bien sûr, un café et une théière ne devraient pas répondre avec un 418.
Jasper
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.