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 des 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 requête ; parce que 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 lui-même (s'il est légitime) et ne demander à l'API de "se faire" qu'avant.

Exiger des cookies peut rendre cela difficile. Pour les clients autres que les navigateurs, la gestion des cookies est un gros inconvénient par rapport aux paramètres de requête, aux en-têtes de requête simples ou au corps de la requête. En revanche, dans les navigateurs, l’utilisation de cookies peut simplifier beaucoup de choses.

Ainsi, une API peut d’abord rechercher dans l’en- Authorizationtête les données d’authentification dont elle a besoin, car c’est probablement l’endroit où les clients autres que les navigateurs préfèrent la placer, mais pour simplifier et rationaliser les clients basés sur un navigateur, elle peut également rechercher un cookie de session. pour la connexion côté serveur, mais uniquement si l'en- Authorizationtête habituel était manquant.

Un autre exemple pourrait être une demande complexe qui nécessite normalement beaucoup de paramètres. Un client non interactif n'aurait aucune difficulté à 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 (un ensemble de pages "magicien") afin que les utilisateurs ne soient pas présentés. avec des options qui ne sont pas applicables en fonction des sélections précédentes. Toutes les pages intermédiaires peuvent stocker les valeurs dans des cookies côté client, de sorte que seule la toute dernière page, où l'utilisateur soumet réellement la demande, ait un effet côté serveur. L'API pourrait rechercher les attributs nécessaires dans le corps de la demande et se tourner vers les cookies si les paramètres nécessaires n'existaient pas.

Edit: dans RE to @ Konrad commentaire ci-dessous:

Les jetons en comparaison sont plus difficiles à mettre en œuvre, en particulier 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 que ce sera le cas. Ce cookie peut ê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é un macaron. La manière dont cela est transmis entre le client et le serveur (par cookie, 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 - Cela dépend de votre utilisation.

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, sont alors reposants.

Si vous enregistrez l'état du serveur dans le cookie, vous ne faites que déplacer la charge sur le client, ce qui n'est pas reposant.

Alors, quels sont quelques exemples?

Reposant:

• Détails de l'authentification ou 'est connecté'
• Dernière page ou lieu visionné dans l'application, etc.

Pas reposant:

• Stockage des informations de session

La tranquillité vient de l’état apatride - du serveur. Les clients peuvent conserver l’état de l’application et l’envoyer au serveur pour lui 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 des requêtes passées pour ainsi dire, les applications reposantes ne le sont idéalement pas (il n'est pas viable d'avoir une application reposante à 100% si vous allez avoir un écran de connexion :)

On peut utiliser des cookies. Le reste leur permet.

REST requiert que toutes les informations de session soient stockées du côté client, mais en ce qui concerne l'authentification, certaines informations doivent rester du côté du serveur pour des raisons de sécurité.

D'un de mes blogs messages , il y a un accord général que les données d'authentification est considérée comme hors de portée concernant le repos. Par conséquent, il est normal que les serveurs conservent certaines de ces données de session.