Échec de la connexion RESTful: Renvoyer 401 ou une réponse personnalisée
C'est une question conceptuelle.
J'ai une application client (mobile) qui doit prendre en charge une action de connexion contre un service Web RESTful. Étant donné que le service Web est RESTful, cela revient à ce que le client accepte un nom d'utilisateur/mot de passe de l'utilisateur, vérifie ce nom d'utilisateur/mot de passe avec le service, puis se rappelle simplement d'envoyer ce nom d'utilisateur/mot de passe avec toutes les demandes ultérieures.
Toutes les autres réponses de ce service Web sont fournies au format JSON.
La question est la suivante: lorsque j'interroge le service Web simplement pour savoir si un nom d'utilisateur/mot de passe donné est valide, le service Web doit-il toujours répondre avec des données JSON me indiquant que l'opération a abouti ou non, ou doit-il renvoyer HTTP 200 avec de bonnes informations d'identification et HTTP? 401 sur les mauvaises informations d'identification.
La raison pour laquelle je pose cette question est que d'autres services RESTful utilisent 401 pour les informations d'identification incorrectes, même lorsque vous demandez simplement si les informations d'identification sont valides. Toutefois, si j'ai bien compris les réponses 401, elles représentent une ressource à laquelle vous n'êtes pas censé avoir accès sans informations d'identification valides. Mais la ressource de connexion DEVRAIT être accessible à quiconque car son objectif est de vous dire si vos informations d'identification sont valides.
En d'autres termes, il me semble qu'une demande comme:
myservice.com/this/is/a/user/action
doit renvoyer 401 si de mauvaises informations d'identification sont fournies. Mais une demande comme:
myservice.com/are/these/credentials/valid
ne doit jamais renvoyer 401 car cette URL (demande) particulière est autorisée avec ou sans informations d'identification valides.
J'aimerais entendre des opinions justifiées d'une manière ou d'une autre à ce sujet. Quelle est la manière habituelle de gérer cela et celle-ci est-elle logiquement appropriée?
Tout d'abord. 401 est le code de réponse approprié à envoyer en cas d'échec de la connexion.
401 non autorisé Semblable à 403 interdit, mais spécifiquement utilisé lorsque l'authentification est requise et a échoué ou n'a pas encore été fournie. La réponse doit inclure un champ d’en-tête WWW-Authenticate contenant un défi applicable à la ressource demandée.
Votre confusion à propos de, myservice.com/are/these/credentials/valid renvoyer 401 lorsque vous faites juste un contrôle, je pense que cela est basé sur le fait que faire des requêtes booléennes dans REST est souvent erroné par les contraintes RESTful. Chaque demande doit retourner une ressource. Les questions booléennes dans un service RESTful sont un sloop glissant jusqu'à RPC.
Maintenant, je ne sais pas comment se comportent les services que vous avez regardés. Mais un bon moyen de résoudre ce problème est d’avoir quelque chose comme un objet Account, que vous essayez d’obtenir. Si vos informations d'identification sont correctes, vous obtiendrez l'objet Compte, si vous ne voulez pas gaspiller de la bande passante juste pour un "contrôle", vous pouvez faire un HEAD sur la même ressource.
Un objet de compte est également un endroit agréable pour stocker toutes ces valeurs booléennes qui seraient autrement difficiles à créer pour des ressources individuelles.
401 doit être envoyé uniquement lorsque la demande nécessite un champ d'en-tête d'autorisation et que l'autorisation échoue. Puisque l'API de connexion ne nécessite pas d'autorisation, le code d'erreur 401 est donc incorrect, à mon avis.
Selon le standard ici https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
* 10.4.2 401 non autorisé
La demande nécessite une authentification de l'utilisateur. La réponse DOIT inclure un champ d'en-tête WWW-Authenticate (paragraphe 14.47) contenant un défi applicable à la ressource demandée. Le client PEUT répéter la demande avec un champ d'en-tête d'autorisation approprié (section 14.8). Si la demande contient déjà des informations d'identification d'autorisation, la réponse 401 indique que l'autorisation a été refusée pour ces informations d'identification. Si la réponse 401 contient le même défi que la réponse précédente et que l'agent utilisateur a déjà tenté l'authentification au moins une fois, il DEVRAIT alors présenter à l'entité qui a été donnée dans la réponse, cette entité pouvant inclure des informations de diagnostic pertinentes. L'authentification d'accès HTTP est expliquée dans "Authentification HTTP: Authentification d'accès de base et Digest" [43]. *