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

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.

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.

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.

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 .

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.