Les cookies doivent-ils être utilisés dans une API RESTful?
Je suis particulièrement intéressé par la façon dont les utilisateurs effectuent les opérations autorisées/authentifiées sur une API Web.
Les cookies d'authentification sont-ils compatibles avec la philosophie REST, et pourquoi?
Un service ReSTful idéal permet aux clients (qui ne sont peut-être pas dans le navigateur) d'effectuer toute tâche nécessaire en une seule demande ; car l'état complet nécessaire pour le faire est détenu par le client, pas par le serveur. Étant donné que le client a le contrôle total de l'état, il peut créer l'état de son propre chef (si cela est légitime) et ne parler à l'API que pour "faire".
Exiger des cookies peut rendre cela difficile. Pour les clients en plus des navigateurs, la gestion des cookies est un inconvénient assez important par rapport aux paramètres de requête, aux en-têtes de requête simples ou au corps de la requête. D'un autre côté, dans le navigateur, l'utilisation de cookies peut simplifier beaucoup de choses.
Ainsi, une API peut d'abord rechercher dans l'en-tête Authorization les données d'authentification dont elle a besoin, car c'est probablement l'endroit où les clients non-navigateurs préféreront les mettre, mais pour simplifier et rationaliser les clients basés sur le navigateur, cela pourrait vérifie également un cookie de session pour la connexion côté serveur, mais uniquement si l'en-tête Authorization normal était manquant.
Un autre exemple pourrait être une demande complexe qui nécessite normalement beaucoup de paramètres définis. Un client non interactif n'aurait aucun problème à brouiller toutes ces données dans une seule demande, mais une interface basée sur un formulaire HTML pourrait préférer diviser la demande en plusieurs pages (quelque chose comme un ensemble de pages "assistant") afin que les utilisateurs ne soient pas présentés avec des options qui ne sont pas applicables sur la base des sélections précédentes. Toutes les pages intermédiaires peuvent stocker les valeurs dans les cookies côté client, de sorte que seule la toute dernière page, où l'utilisateur envoie réellement la demande, ait un effet secondaire sur le serveur. L'API pourrait rechercher les attributs nécessaires dans le corps de la demande et se replier sur les cookies si les paramètres nécessaires n'étaient pas là.
Modifier: dans RE au commentaire de @ Konrad ci-dessous:
Les jetons en comparaison sont plus difficiles à implémenter, surtout parce que vous ne pouvez pas facilement invalider le jeton sans les stocker quelque part.
euh ... vous validez les cookies côté serveur, non? Ce n'est pas parce que vous avez dit au navigateur de supprimer un cookie après 24 heures qu'il le fera. Ce cookie pourrait être enregistré par un utilisateur hautement technique et réutilisé longtemps après son "expiration".
Si vous ne souhaitez pas stocker les données de session côté serveur, vous devez les stocker dans le jeton (cookie ou autre). Un jeton d'authentification autonome est parfois appelé Macaroon. La façon dont cela est transmis entre le client et le serveur (que ce soit par cookie, en tant qu'en-têtes supplémentaires ou dans l'entité de requête elle-même) est totalement indépendante du mécanisme d'authentification lui-même .
Oui et non - dépend de la façon dont vous l'utilisez.
Les cookies s'ils sont utilisés pour maintenir l'état du client chez le client, pour le client, par le client et par le client, ils sont alors reposants.
Si vous stockez l'état du serveur dans le cookie, vous déplacez simplement la charge vers le client - ce qui n'est pas reposant.
Alors, quels sont quelques exemples?
Reposant:
- Détails d'authentification ou "est connecté" un peu
- dernière page consultée ou place dans l'application, etc.
Pas reposant:
- Stockage des informations de session
L'agitation vient de l'apatridie - du serveur. Les clients peuvent maintenir l'état de l'application et l'envoyer au serveur pour dire où ils se trouvent afin que le serveur puisse décider où aller à partir de là. Fondamentalement, les sessions/États ont besoin de données historiques et dépendent pour ainsi dire des demandes passées, les applications reposantes ne le sont pas idéalement (il n'est pas viable d'avoir une application reposante 100% pure si vous voulez avoir un écran de connexion :)
On peut utiliser des cookies. REST le permet.
REST requiert que toutes les informations de session soient stockées côté client, mais en matière d'authentification, certaines informations doivent rester côté serveur pour des raisons de sécurité.
Depuis l'un de mes blogs posts , il y a un accord général que les données d'authentification sont considérées comme hors de portée concernant REST. Par conséquent, les serveurs peuvent conserver certaines de ces données de session de leur côté.