Code de réponse REST pour les données invalides

Question

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

1. Données non valides transmises lors de l'enregistrement de l'utilisateur, comme un format d'e-mail incorrect.
2. Le nom d'utilisateur ou l'adresse électronique existe déjà

J'ai choisi la 403. J'ai également trouvé les éléments suivants qui me semblent pouvoir être utilisés.

Wikipedia :

412 Échec de la précondition Le serveur ne remplit pas l'une des conditions préalables que le demandeur a demandées. a mis sur la demande

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

Answer 1

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

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

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

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

Answer 2

Je recommande le 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.

En RFC 4918 :

Le code d'état 422 (Unprocessable Entity) signifie que le serveur comprend le type de contenu de l'entité de demande (le code d'état 415 (Unsupported Media Type) est donc inapproprié) et que la syntaxe de l'entité de demande est correcte (le code d'état 400 (Bad Request) est donc inapproprié), mais qu'il n'a pas pu traiter les instructions contenues. Par exemple, cette condition d'erreur peut se produire si un corps de demande XML contient des instructions XML bien formées (c'est-à-dire syntaxiquement correctes), mais sémantiquement erronées.

Answer 3

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

RFC 4918 déclare que 422 Entité non traitable est applicable lorsque l'entité de la demande est syntaxiquement bien formée, mais sémantiquement erronée. Ainsi, si l'entité de la demande est confuse (comme un mauvais format de courriel), utilisez 400 ; mais si elle n'a tout simplement pas de sens (comme @example.com ) utiliser 422.

Si le problème est que, comme indiqué dans la question, le nom d'utilisateur et l'adresse électronique existent déjà, vous pouvez utiliser la méthode suivante 409 Conflit [ 2 ] avec une description du conflit, et une indication sur la façon de le résoudre (dans ce cas, "choisir un autre nom d'utilisateur/email"). Cependant, dans la spécification telle qu'elle est écrite, 403 Interdit [ 3 ] peut également être utilisé dans ce cas, malgré les arguments concernant l'autorisation HTTP.

412 Échec de la précondition [ 4 ] est utilisé lorsqu'un en-tête de requête de précondition (par exemple If-Match ) qui était fourni par le client a pour valeur false. En d'autres termes, le client a demandé quelque chose et a fourni des conditions préalables, en sachant pertinemment que ces conditions préalables pourraient échouer. 412 ne devrait jamais être imposée au client de façon impromptue et ne devrait pas être liée à l'entité de la demande. en soi .

Answer 4

Il est amusant de revenir 418 I'm a teapot à des demandes manifestement fabriquées ou malveillantes et "impossibles", comme l'échec de la vérification CSRF ou l'absence de propriétés de la demande.

2.3.2 418 Je suis une théière

Toute tentative d'infusion de café avec une théière devrait entraîner l'erreur suivante code d'erreur "418 I'm a teapot". Le corps de l'entité qui en résulte PEUT être court et robuste.

Pour rester sérieux, je limite l'utilisation des codes d'erreur amusants aux points d'accès RESTful qui ne sont pas directement exposés à l'utilisateur.