REST code de réponse pour les données non valides
Quel code de réponse doit être transmis au client dans les cas suivants?
- Données non valables transmises lors de l'enregistrement de l'utilisateur comme format de courrier électronique incorrect
- Nom d'utilisateur/Email existe déjà
J'ai choisi 403. J'ai aussi constaté que je pouvais utiliser ce qui suit.
Wikipédia:
412 Precondition Failed: le serveur ne remplit pas l'une des conditions préalables définies par le demandeur pour la demande.
Suggérez du code si je devais utiliser un 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 motif ou inclure un corps pour l'expliquer.
412 - La précondition ayant échoué est utilisée pour les demandes conditionnelles lors de l'utilisation de la date de dernière modification et des balises 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. Cela ne fait pas partie de la spécification HTTP principale, mais il est défini par une norme publique (WebDAV) et devrait être traité par les navigateurs de la même façon que tout autre code d'état 4xx.
De RFC 4918 :
Le code de statut 422 (entité non traitable) signifie que le serveur comprend le type de contenu de l'entité de demande (par conséquent, un code de statut 415 (type de support non pris en charge) est inapproprié), et la syntaxe de l'entité de demande est correcte (par conséquent, une requête de type 400 (requête incorrecte)). ) 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 Requête incorrecte [ 1 ].
RFC 4918 indique que 422 Entité non traitable est applicable lorsque l'entité de demande est syntaxiquement correcte, mais erronée du point de vue de la sémantique. Donc, si l'entité de la demande est brouillée (comme un mauvais format de courrier électronique), utilisez 400; mais si cela n'a aucun sens (comme @example.com), utilisez 422.
Si le problème est que, comme indiqué dans la question, le nom d'utilisateur/email existe déjà, vous pouvez utiliser 409 Conflict [ 2 =] avec une description du conflit et une astuce sur la façon de le résoudre (dans ce cas, "choisissez un autre nom d'utilisateur/e-mail"). Cependant, dans la spécification telle qu'écrite, 403 Interdit [] peut également être utilisé dans ce cas, les arguments relatifs à l'autorisation HTTP nonobstant .
412 Echec de la précondition [ 4 ] est utilisé lorsqu'un en-tête de demande de précondition (par exemple If-Match) qui était fourni par le client est évalué à false. En d'autres termes, le client a demandé quelque chose et a fourni les conditions préalables, sachant pertinemment que ces conditions préalables pourraient échouer. 412 ne devrait jamais être jeté sur le client à l'improviste et ne devrait pas être lié à l'entité de la demande en soi .
Il est amusant de retourner 418 I'm a teapot aux demandes manifestement conçues ou malveillantes et "ne pouvant se produire", telles que l'échec du contrôle 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 générer le code d'erreur "418 je suis une théière". Le corps d'entité résultant peut être court et gros.
Pour rester assez 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.