Comment garder les applications sans état

97

C'est peut-être une question compliquée, mais j'essaie de mieux comprendre l'apatridie.

D'après ce que j'ai lu, les applications Web devraient être sans état, ce qui signifie que chaque demande est traitée comme une transaction indépendante. Par conséquent, les cookies de session et les cookies doivent être évités (car ils sont tous deux à état dynamique). Une meilleure approche consiste à utiliser des jetons, qui sont sans état, car rien n’est stocké sur le serveur.

J'essaie donc de comprendre comment les applications Web peuvent être sans état si des données sont conservées pour ma session (telles que des éléments dans un panier). Celles-ci sont-elles réellement stockées dans une base de données quelque part, puis purgées périodiquement? Comment cela fonctionne-t-il lorsque vous utilisez un jeton au lieu de cookies?

Et puis, comme question connexe, les principaux sites Web (Amazon, Google, Facebook, Twitter, etc.) sont-ils réellement sans état? Utilisent-ils des jetons ou des cookies (ou les deux)?


la source
38
J'ai récemment rencontré des développeurs obsédés par l'apatridie au point de les distraire. Il est agréable d’être apatride pour pouvoir être réutilisé, mais il n’est pas réaliste de poursuivre cet objectif dans toutes les situations, sauf si vous avez beaucoup de ressources pour le faire pour une raison quelconque, telle que l’échelle.
Mark Rogers
4
@ MarkRogers Pourquoi? L'apatridie n'a rien à voir avec la réutilisabilité. Et être apatride ne conduit pas à un effort plus élevé.
Paul Wasilewski
3
@PaulWasilewski: Et être apatride ne conduit pas à un effort plus grand. => c’est le cas, avec une application dynamique, vous gardez tout en mémoire lié à la session. Cela ne fonctionne pas bien, bien que cela fonctionne avec l'épinglage de session, mais c'est TRÈS simple. Lorsque des serveurs doivent commencer à échanger des informations entre eux, des problèmes commencent.
Matthieu M.
6
En regardant sur Amazon, vous remarquerez que votre panier reste en place même si vous changez d'ordinateur. Il n'est donc pas stocké dans un cookie, mais dans une base de données.
njzk2
20
Si vous n'arrivez pas à lire ma réponse. Voici la version courte: Les demandes Web sont intrinsèquement sans état. Les applications Web ne le sont pas. (Peu importe ce que vous disent des dogmatistes "web sans état"!)
svidgen

Réponses:

95

"les applications Web doivent être sans état" doit être compris comme "les applications Web doivent être sans état, sauf s'il existe une très bonne raison d'avoir un état" . Un "panier" est une fonctionnalité dynamique par conception, et le nier est tout à fait contre-productif. L'intérêt du modèle de panier d'achat est de préserver l'état de l'application entre les demandes.

Une alternative que je pourrais imaginer en tant que site Web sans état et implémentant un panier serait une application d'une seule page qui garde le panier entièrement côté client, récupère les informations sur le produit avec des appels AJAX, puis les envoie au serveur en une fois lorsque l'utilisateur effectue une commande. Mais je doute avoir déjà vu quelqu'un le faire, car cela ne permet pas à l'utilisateur d'utiliser plusieurs onglets de navigateur et ne conserve pas son état lorsqu'ils le ferment par inadvertance. Bien sûr, il existe des solutions de contournement telles que l’utilisation de localstorage, mais vous avez à nouveau l’état, uniquement sur le client plutôt que sur le serveur.

Chaque fois que vous avez une application Web nécessitant de conserver des données entre les pages vues, vous le faites généralement en introduisant des sessions. La session à laquelle une demande appartient peut être identifiée par un cookie ou par un paramètre d'URL que vous ajoutez à chaque lien. Les cookies doivent être préférés car ils gardent vos URL plus pratiques et empêchent votre utilisateur de partager accidentellement une URL avec l'identifiant de session qu'il contient. Mais avoir des jetons d'URL comme solution de secours est également vital pour les utilisateurs qui désactivent les cookies. La plupart des frameworks de développement Web ont un système de gestion de session qui peut le faire directement.

Du côté du serveur, les informations de session sont généralement stockées dans une base de données. La mise en cache en mémoire côté serveur est facultative. Cela peut grandement améliorer le temps de réponse, mais ne vous permettra pas de transférer des sessions entre différents serveurs. Donc, vous aurez besoin d'une base de données persistante comme solution de secours.

les principaux sites Web (Amazon, Google, Facebook, Twitter, etc.) sont-ils réellement sans état? Utilisent-ils des jetons ou des cookies (ou les deux)?

Est-ce qu'ils vous permettent de vous connecter? Lorsque vous fermez ensuite l'onglet et revenez sur le site, êtes-vous toujours connecté? Si vous l'êtes, ils utilisent des cookies pour préserver votre identité entre les sessions.

Philipp
la source
46
Je pense que l’une des confusions ici est la distinction entre une "application Web" au sens large du point de vue de l’utilisateur, et "une application Web" au sens étroit de "le code exécuté sur le serveur Web". On prétend souvent que ce dernier est apatride et non l'ancien. Comme vous le dites, il n’a aucun sens pour les premiers d’être apatrides en général, car l’état fait généralement partie de la logique commerciale. Pour que ce dernier soit sans état, cela signifie simplement que cet état doit être stocké sur le client ou sur le serveur de base de données, ou sur les deux, et non sur le serveur Web.
Derek Elkins
16
"[...] mais alors vous avez à nouveau l'état, juste sur le client plutôt que sur le serveur." Il s’agit de ne pas avoir d’état côté serveur, pour obtenir une meilleure évolutivité et disponibilité. Si un état est stocké côté client, peu importe.
Paul Wasilewski
5
@ njzk2 pouvez-vous élaborer pour que cela ne semble pas absurde? Les utilisateurs ne vont pas sur Amazon pour acheter plus de noms. Et, après avoir effectué leur achat, quelque chose disparaît qui n’existait que pendant leurs achats. Si ce quelque chose n'est pas "l'état de l'application", alors de quoi s'agit-il? Si les applications n'ont pas d'état, qu'ont-elles?
3
@nocomprende: Je pense que l'essentiel de njzk2 est que le contenu de votre panier, tout comme votre nom complet, contient des données indiquant qu'une application Web persiste côté serveur. Lorsque les gens disent que "les applications Web doivent être sans état", elles signifient généralement autre chose que "les applications Web ne doivent pas accéder à une base de données contenant votre nom complet associé à votre nom d'utilisateur". Précisément ce qu'ils ne veulent dire par « apatride » n'est pas défini trivialement, car une fois que vous avez peut - être cette base de données il y a toutes sortes de bêtises que vous pourriez persister là - bas, pour soutenir l' état de l' application trop complexe, mais ne devrait pas ;-)
Steve Jessop
4
@nocomprende: corrigez un œuf en rétablissant la base de données: puisque notre application Web est apatride, elle peut reprendre comme avant ;-)
Steve Jessop
56

Il est vrai que les applications Web doivent être sans état. Cependant, les variables de session, les cookies et les jetons n'enfreignent pas cette règle lorsqu'ils sont tous stockés sur le client (navigateur Web). Ils peuvent être des paramètres dans la requête.

Voici un modèle simplifié:

Web Browser (has state) <-> Web Server (stateless) <-> Database (has state)

Cela pourrait fonctionner pour Software Engineering Stack Exchange . Cette réponse que je tape fait partie de l'état de mon navigateur Web. Tant que c'est le seul endroit où il se trouve, il n'est accessible à personne d'autre que moi. Mais dès que je frappe, Post your Answermon navigateur l’envoie au serveur Web. Le serveur Web traite la publication sans utiliser aucun état. Il apprend qui je suis à partir de mon navigateur et de la base de données. Une fois la vérification de mon message terminée et son ajout à la base de données, le serveur Web oublie rapidement mes informations.

C'est ce que veut dire apatride. Le serveur n'est pas responsable de se souvenir de cela. Ce n'est pas son travail.

Cela présente de nombreux avantages. Si le serveur Web présente une fuite de mémoire, elle est détectable car son empreinte mémoire ne devrait pas augmenter. Si le serveur Web se bloque, mon identité ne va pas avec. Si une personne tente de faire une attaque par déni de service, elle ne peut pas utiliser les ressources d'état du serveur Web pour le faire, car le serveur Web ne leur alloue aucun état entre les sessions. Tout cela vise à rendre le serveur Web stable. De cette façon, quand il commence à fonctionner, il continue à fonctionner.

Bien sûr, je consomme des ressources dans la base de données, mais ces ressources ont d'abord été vérifiées par rapport à une réserve stable sur laquelle nous pouvons compter pour protéger la base de données du Web sauvage et laineux: le serveur Web apatride et respectant les règles de gestion.

confits_orange
la source
8
Je ne sais pas ... Cette réponse ressemble un peu à dire: " Excel ne stocke pas votre feuille de calcul, mais le lecteur de disque le fait!" Ha ha, la base de données ne fait-elle pas partie du serveur Web, pour la plupart des gens? Évidemment, l'état n'est pas stocké dans la CPU ou le code du serveur, et le garder en mémoire est assez ridicule.
7
@nocomprende Non, la base de données ne fait généralement pas partie de votre serveur Web. Oui, le stockage de l'état dans une base de données limite probablement l'évolutivité de l'application dans son ensemble, mais relativement peu d'applications peuvent décharger tout leur état (ou même tout l'état "par utilisateur") sur le client. Les serveurs de base de données sont spécifiquement conçus pour gérer de manière évolutive les états et, comme le mentionne CandiedOrange, ils sont généralement mieux protégés, mis en service et contrôlés que les serveurs Web. Il est avantageux de pouvoir facilement faire évoluer les serveurs Web, même si cela ne résout pas tous les problèmes d'évolutivité.
Derek Elkins
9
@nocomprende: L'intérêt de dire que la base de données ne fait pas partie du serveur Web, c'est que vous pouvez avoir une seule base de données (ou un cluster de bases de données) pour 1, 2, 3, .... serveurs Web. C’est la raison pour laquelle être sans état est censé augmenter l’évolutivité: vous pouvez mettre à l’échelle le cluster de bases de données et le nombre de serveurs Web de manière indépendante.
Matthieu M.
6
"Il est vrai que les applications Web doivent être sans état." Non, c'est un non-sens complet.
svidgen
4
Cette réponse est celle que j’aime le mieux, car elle illustre le mieux l’utilisation du terme "sans état" dans le développement Web. Le serveur ne maintient pas l'état entre les demandes. Tous les états doivent provenir du client (c.-à-d. Une partie de la demande) ou de la base de données (probablement en fonction de la demande). Soit dit en passant, il y a souvent un état dans l'application Web (par exemple, des instances statiques), mais en général, vous voudriez que les choses soient conçues comme étant sans état. Cette réponse semble meilleure que celle acceptée pour mieux expliquer l'idée d'apatridie.
Kat
30

les applications Web doivent être sans état

Absurdité. Les demandes Web doivent être sans état. Ou plus précisément, les requêtes Web sont sans état.

Mais dire qu'une application entière doit être apatride est un non-sens.

chaque demande est traitée comme une transaction indépendante.

Oui, exactement . Ou plus précisément, oui, nécessairement . Sur HTTP, chaque demande est intrinsèquement indépendante de toutes les autres demandes. L'ajout de "statefulness" à HTTP nécessite que vous identifiiez, stockiez et récupériez explicitement "state" pour chaque requête "stateful". Et cela demande des efforts, diminue les performances et ajoute à la complexité.

Et, pour ces raisons, chaque demande qui peut être apatride "devrait" être apatride.

Par conséquent, les cookies de session et les cookies doivent être évités (car ils sont tous deux à état dynamique). Une meilleure approche consiste à utiliser des jetons

Quelques éléments: Les jetons peuvent également être liés au stockage de session. Les cookies ne doivent pas nécessairement être liés au stockage de session. Les jetons sont souvent stockés dans des cookies. Et parfois, une session est simplement le bon outil pour le travail.

Cela signifie qu'au moins parfois , les sessions et les cookies sont tout aussi "meilleurs" que les jetons!

Les [jetons] sont sans état car rien n'est stocké sur le serveur.

Eh bien c'est ça. C'est ce que le dogme de "l'apatridie" est vraiment. Bien que, pour être clair, il ne s’agisse pas de stocker "rien" sur le serveur, il s’agit de ne pas stocker l’ état de la session sur le serveur.

Ma boîte de réception Gmail est dans un état, par exemple. Et il vaut bien mieux que ce soit stocké sur le serveur! Mais ce n'est pas l' état de la session .

Ainsi, au lieu de disposer de serveurs capables de prendre un petit identifiant et de déterminer qui vous êtes et ainsi de suite, les applications sans état veulent vous rappeler qui vous êtes et ce que vous faites avec chaque requête sanglante. L'état de l'application existe toujours, le client est simplement responsable de la conserver.

Maintenant, si cet état est petit, c'est probablement OK. Dans certains cas, c'est très bien.

Et puis, bien sûr, il y a des choses que nous nous attendons simplement à être stateful

Comment les applications Web peuvent-elles être sans état lorsqu'une donnée est conservée pour ma session (telle que des éléments d'un panier d'achat)? Celles-ci sont-elles réellement stockées dans une base de données quelque part, puis purgées périodiquement?

Deux options. Ou vous avez une session, ou vous êtes dans le déni!

... Mais sérieusement. Vous ne devriez normalement pas stocker un panier dans un cookie. Quelque chose comme un panier d'achat sera soit stocké dans une session "traditionnelle", soit en tant Cartqu'objet, avec une sorte d'identifiant que le serveur utilisera pour extraire celui-ci dans les requêtes suivantes. Un peu comme une ... euh ... euh ... session ...

Sérieusement, il existe une grande partie de ce que nous appelons "étatfulness" lorsque deux agents en communication peuvent contextualiser des messages dans une conversation. Et une session, traditionnellement comprise, est ce que nous appelons généralement le mécanisme par lequel cela se produit.

Je dirais que, que vous utilisiez des jetons ou des "sessions", pour chaque demande traitée par votre serveur, vous devez soit contextualiser cette demande pour la remplir, soit ne pas le faire. Si le contexte n'est pas nécessaire, ne le récupérez pas. Si le contexte est nécessaire, vous feriez mieux de l'avoir à proximité!

Et puis, comme question connexe, les principaux sites Web (Amazon, Google, Facebook, Twitter, etc.) sont-ils réellement sans état? Utilisent-ils des jetons ou des cookies (ou les deux)?

Probablement les deux. Mais, en général, ils font exactement ce que vous faites: ils configurent les cookies pour identifier les enregistrements "d'état" dans des bases de données "session" massives.

Dans la mesure du possible, je soupçonne qu'ils transforment les revendications d'identité de base en "jetons" de courte durée pour éviter des conflits inutiles sur le stockage centralisé. Cependant, le fait que nombre de ces services me permettent de "me déconnecter de tous les autres sites" est un bon indicateur que, s'ils utilisent des jetons, ils sont au moins "pris en charge" par un modèle de session semi-traditionnel. .

svidgen
la source
3
Se mettre d'accord. Cela me rappelle l'idée des "données immuables". S'il est immuable, sculptez-le dans un rocher, ne gaspillez pas un ordinateur pour le faire. Laissez les ordinateurs faire des choses avec des données! C'est pourquoi nous les avons construits! Les applications fonctionnent avec des données. Des données constantes sont inutiles.
@nocomprende FYI, je ferai un addendum à cela plus tard. J'ai l'impression que ma réponse manque une partie de la question sous-jacente du PO. Parce que, il est une préoccupation légitime flottant derrière l'idée « d'application sans état ». Mais la réponse est similaire à celle-ci: lorsque les gens disent «sans état», ils veulent dire: «repose peu sur des sessions côté serveur».
svidgen
4
@nocomprende: les structures de données immuables sont quelque chose de différent et constituent un outil utilisé pour gérer le cycle de vie des objets de mémoire.
Whatsisname
1
Aimez votre première ligne d'explication. Lorsque nous discutons de quelque chose, chaque déclaration verbale que nous faisons se dissipe instantanément dans l'oubli. Mais d’une manière ou d’une autre, nous sommes toujours en mesure de tenir une conversation, hein? C'est magique!
1
@nocomprende C'est une discussion intéressante, mais je suppose que nous ne devrions pas continuer ici.
Pabrams
14

L'état de mémoire n'est pas nécessairement une mauvaise chose, mais vous devez comprendre la différence entre les applications avec état et sans état. En bref, les applications avec état conservent des informations sur la session en cours, contrairement aux applications sans état. Les informations stockées de manière permanente dans le cadre d'un compte d'utilisateur peuvent ou non être stockées dans une session, mais le stockage d'informations relatives à un compte d'utilisateur ne confère pas à l'application un état dynamique. La mise en état nécessite que le serveur conserve des informations sur la session de l'utilisateur actuel, au-delà de ce que le navigateur client gère. Par exemple, un client peut s'authentifier et recevoir un cookie JSESSIONID, qu'il envoie ensuite au serveur à chaque demande. Si le serveur commence à stocker des éléments dans l'étendue de session de l'application en fonction de ce JSESSIONID, il devient dynamique.

Apatridie

Par sans état, nous voulons dire que le serveur et le client ne conservent pas les informations actuelles sur la session utilisateur. Le client et le serveur peuvent utiliser une forme de jeton pour assurer l'authentification entre les demandes, mais aucune autre information actuelle n'est stockée. Un cas d'utilisation typique pour une telle solution pourrait être un site de nouvelles où la plupart des utilisateurs (nouveaux consommateurs) consomment des informations sans produire d'informations renvoyant au site. Dans ce cas, le site n'a pas besoin de conserver d'informations sur la session utilisateur en cours. Notez que le site peut toujours utiliser des cookies pour identifier l'utilisateur et stocker des informations sur l'utilisation du site par cet utilisateur, mais cela peut toujours être considéré comme sans état, dans la mesure où tout ce qui est enregistré peut être transactionnel, par exemple le lien sur lequel l'utilisateur a cliqué, qui pourrait être enregistré par le serveur, mais pas maintenu dans une session d'utilisateur.

Statefulness sur le serveur

Sur le serveur, une application avec état enregistre les informations d'état concernant les utilisateurs actuels. Cette approche implique généralement l'utilisation de cookies pour identifier le système de l'utilisateur afin que cet état puisse être maintenu sur le serveur entre les demandes. Les sessions peuvent ou non être authentifiées, en fonction du contexte de l'application. Les applications de serveur avec état offrent l'avantage de mettre en cache les informations d'état de l'utilisateur sur le serveur, d'accélérer les recherches et le temps de réponse des pages. Inconvénient, stocker des informations dans l'étendue de la session coûte cher et, à grande échelle, cela nécessite beaucoup de ressources. Il crée également un vecteur d’attaque potentiel permettant aux pirates d’essayer de détourner les identifiants de session et de voler les sessions utilisateur. Les applications de serveur avec état ont également pour défi de protéger les sessions utilisateur contre les interruptions de service inattendues, telles que les pannes de serveur.

Statefulness sur le client

À l'aide de JavaScript et de technologies de navigation modernes telles que sessionStorage, les applications peuvent désormais stocker facilement des informations sur l'état d'une session utilisateur sur le périphérique de cet utilisateur. Dans l’ensemble, l’application peut toujours être considérée comme un état, mais le travail de maintien de l’état a été déplacé vers le client. Cette approche présente un gros avantage (pour le responsable de l'application Web) par rapport au maintien de l'état sur le serveur, dans la mesure où chaque utilisateur maintient son propre état et que l'infrastructure du serveur n'est pas surchargée. À l'échelle du Web, ce type de choix architectural a d'énormes répercussions sur les coûts de matériel et d'électricité. Le maintien de l'état sur le serveur pourrait coûter des millions de dollars par an. Passer à un système maintenant le système sur le client pourrait alors économiser des millions de dollars par an.

Jetons v. Cookies

Les cookies agissent comme des identifiants pour les appareils clients / navigateurs. Ils peuvent être utilisés pour stocker toutes sortes de choses, mais généralement, ils stockent une forme d'identifiant, comme CFID / CFTOKEN dans les applications CFML. Les cookies peuvent être configurés pour vivre longtemps dans le navigateur de l'utilisateur, ce qui permet par exemple de maintenir l'authentification sur une application entre les sessions du navigateur. Les cookies peuvent également être configurés uniquement en mémoire afin qu'ils expirent lorsqu'un utilisateur ferme le navigateur.

Les jetons sont généralement une sorte d'informations d'identification sur l'utilisateur générées sur le serveur (en utilisant un cryptage pour brouiller les informations), transmises au client et renvoyées au serveur avec la requête suivante. Ils peuvent être transmis dans l'en-tête de la demande et de la réponse, ce qui est un modèle courant dans les applications à page unique. Idéalement, chaque requête / réponse génère un nouveau jeton. Par conséquent, les jetons ne peuvent pas être interceptés et utilisés plus tard par un attaquant.

Applications sur une seule page et état du client

Avec les SPA, les informations d'état sont chargées dans le navigateur client et y sont conservées. Lorsque l'état change, par exemple si vous publiez une mise à jour sur votre compte de réseau social, le client relaie cette nouvelle transaction sur le serveur. Dans ce cas, le serveur enregistre cette mise à jour dans un magasin de données persistant, comme une base de données, et retransmet au client les informations dont il a besoin pour se synchroniser avec le serveur en fonction de la mise à jour (par exemple, un ID pour la mise à jour).

Notez que ce modèle d'état de stockage sur le client offre des avantages pour les expériences en ligne / hors ligne dans la mesure où vous pouvez être déconnecté du serveur tout en conservant une application quelque peu utilisable. Twitter est un bon exemple de ce cas, où vous pouvez consulter tout ce qui est chargé côté client dans votre flux Twitter, même si vous êtes déconnecté de l'application du serveur Twitter. Ce modèle crée également une complexité dans la synchronisation entre serveur et client, qui est un sujet à part entière. Les complexités de la solution sont un compromis pour pouvoir maintenir l’état sur le client.

L'état d'état sur le client permet aux applications Web de se sentir et de se comporter davantage comme les applications de bureau traditionnelles. Contrairement aux applications de bureau, toutes les informations de votre compte ne seront généralement pas chargées dans votre session client dans un navigateur. Dans de nombreux cas, cela serait irréalisable et produirait de mauvaises expériences. Pouvez-vous imaginer essayer de charger une boîte Gmail entière dans le navigateur? Au lieu de cela, le client conserve des informations telles que l'étiquette / le dossier que vous consultez et l'emplacement de la liste des courriels de ce dossier que vous recherchez. Équilibrer quelles informations d'état à conserver et que demander selon les besoins est un autre défi technique de ce modèle. Encore une fois, cela représente un compromis entre l'aspect pratique et la fourniture d'une bonne expérience utilisateur.

Chariots de magasinage et similaires

En ce qui concerne les spécificités telles que les paniers d'achat, cela dépend vraiment de la solution. Un panier peut être stocké dans une base de données sur le serveur, il peut être stocké uniquement dans la portée de session sur le serveur ou même dans le client. Amazon propose des paniers d'achat permanents pour les utilisateurs connectés et des paniers "temporaires" pour les utilisateurs anonymes, bien que ces paniers soient persistants dans une certaine mesure.

Lorsque vous parlez de Google, par exemple, qui regroupe différentes applications de la même marque, elles ne partagent probablement pas une architecture commune et chacune est conçue de manière à répondre au mieux aux besoins de ses utilisateurs. Si vous souhaitez savoir comment un site est construit, ouvrez les outils de développement de votre navigateur et consultez-le. Recherchez des cookies, surveillez le trafic réseau et voyez comment il fonctionne.

Désolé si cette réponse décale un peu, mais l'état d'esprit est un sujet complexe.

Robert Munn
la source
6

Les sessions et les cookies ne doivent pas être évités. Vous pouvez toujours les avoir avec des applications Web sans état.

Il y a une grande différence entre Java et Ruby on Rails. Les applications Java vont stocker la session en mémoire en utilisant une clé de session stockée dans un cookie. Cette procédure est rapide pour récupérer l’état de l’utilisateur et le panier. Cependant, vous devez toujours utiliser le même serveur avec votre session.

Les applications Rails stockent l'identifiant de l'utilisateur dans un cookie crypté et signé. Il ne peut pas être altéré. Lorsque vous chargez une page, l'application Web récupère votre état, votre utilisateur et votre panier d'achat à partir d'une base de données. C'est plus lent, mais l'essentiel est que vous puissiez frapper n'importe quel cas ! Cela vous permet de redémarrer, d’échelonner et d’arrêter les instances à volonté. Très pratique. Il peut également être rendu plus rapide avec une base de données cache partagée en mémoire, telle que Redis. Vous pouvez également stocker le panier dans le cookie, à condition qu'il soit suffisamment petit.

Vous pouvez ainsi atteindre l'apatridie, grâce à des techniques intelligentes, et ajouter la possibilité d'évoluer à votre guise.

Chloe
la source
5

Le protocole est apatride.

Mais à partir de là, il ne s'ensuit pas nécessairement que les applications utilisant le protocole doivent être sans état.

Voici quelques réponses StackOverflow associées qui expliquent bien la différence:

SideShowBarker
la source
5

Lorsque vous faites référence à stateless, par exemple dans un service HTTP RESTful, vous évitez de stocker l’état du côté serveur. Au mieux, cela implique également d'éviter de stocker tout état dans une base de données ou dans d'autres stockages persistants sur le backend. Pour que ce soit clair, je parle d'un état et non de données en général. Il semble que certains gars mélangent les choses.

Une communication sans état présente plusieurs avantages, notamment en ce qui concerne l'évolutivité et la disponibilité.

Une meilleure approche consiste à utiliser des jetons, qui sont sans état, car rien n’est stocké sur le serveur.

C'est vrai (pour certains protocoles d'authentification et d'autorisation). Les jetons peuvent (mais non en tant que tels) fournir toutes les informations contenues dans la demande qui sont nécessaires pour authentifier un utilisateur ou autoriser une action. Pour un exemple, jetez un oeil à JWT .

J'essaie donc de comprendre comment les applications Web peuvent être sans état si des données sont conservées pour ma session (telles que des éléments dans un panier). Celles-ci sont-elles réellement stockées dans une base de données quelque part, puis purgées périodiquement? Comment cela fonctionne-t-il lorsque vous utilisez un jeton au lieu de cookies?

Concernant l'exemple du panier d'achat. Ce n'est pas un problème de stocker tous les éléments du panier côté client sans utiliser de session ou de cookies. Vous pouvez trouver un exemple sur smashingmagazine.com . Mais il est également possible de créer un panier d'achat sans état avec des cookies (du moins si votre assortiment n'est pas si grand et qu'un stockage de 4 ko est suffisant pour vous).

Ne vous méprenez pas, cela ne signifie pas que vous deviez mettre en place un panier d'achat apatride à tout prix. Amazon ou d’autres grandes plates-formes de vente en ligne utilisent des implémentations de panier dynamiques, car l’expérience et la convivialité des utilisateurs sont plus importantes pour elles que la satisfaction d’exigences techniques non fonctionnelles telles que l’évolutivité.

En règle générale, les jetons ne sont pas utilisés pour stocker des informations telles que des éléments de panier. Ils sont utilisés pour une authentification et une autorisation sans état.

Et puis, comme question connexe, les principaux sites Web (Amazon, Google, Facebook, Twitter, etc.) sont-ils réellement sans état? Utilisent-ils des jetons ou des cookies (ou les deux)?

Si vous leur demandez s'ils utilisent des cookies ou des jetons pour l'authentification, la réponse est qu'ils utilisent les deux. Les utilisateurs utilisent principalement des cookies pour les clients techniques.

Paul Wasilewski
la source
-2

OK, la règle que vous citez est techniquement incorrecte. Toutes les couches d'une application Web ont un état.

Le but de la règle est "ne conservez pas le côté serveur par session".

C'est-à-dire les variables de session dans ASP , qui étaient couramment utilisées pour faire des choses comme des éléments dans le panier / nom d'utilisateur, etc.

La raison est que vous manquerez de mémoire sur le serveur à mesure que votre application gagnera plus d'utilisateurs. Déplacer le stockage vers une base de données ou un cache partagé ne résout pas le problème car vous avez toujours un goulot d'étranglement.

Pour conserver l'état d'application par utilisateur sans rencontrer ce problème, déplacez l'état vers le côté client. Par exemple, placez les éléments du panier dans un cookie ou dans un stockage plus avancé côté client.

Étant donné que le nombre de clients augmente avec le nombre d'utilisateurs, votre application dans son ensemble n'aura pas de goulot d'étranglement et évoluera bien.

Ewan
la source
2
Bien que les fuites de mémoire et les problèmes de déni de service aient été un facteur, je pense qu'un facteur plus important aujourd'hui est l'élasticité et la robustesse en cas de défaillance d'un serveur Web, qui est bien sûr également lié à l'évolutivité. L'idée est que si un serveur est surchargé ou même en panne, je peux simplement rediriger les demandes futures (et avec un peu plus de soin, même les demandes échouées) vers de nouveaux serveurs Web sans coordination ni perte d'état (comme le voit l'utilisateur).
Derek Elkins
hmm genre de. Si vous avez des informations par utilisateur sur le serveur, même si elles sont distribuées, vous rencontrez toujours un problème d’évolutivité.
Ewan
Il y a beaucoup de choses que vous pouvez faire si extraire des données du disque est un goulot d'étranglement tel que la mise en cache.
JeffO
non, il existe un problème inhérent si vous détenez ces données par session. soit vous le déplacez du serveur Web vers son propre système haute disponibilité, soit vous vous en débarrassez en le déplaçant chez le client
Ewan
1
Toute cette discussion sur le fait d’essayer d’éviter la patate chaude me mystifie beaucoup. Qu'est-ce qui est arrivé au vieil adage qui dit: "Le pouvoir s'arrête ici"? Quelque chose doit gérer les données, ma banque ne voudrait pas que toutes mes informations de transaction financière soient conservées uniquement sur mon ordinateur portable. Pourquoi tout le monde s'enfuit-il en train de crier des données? C'est pourquoi nous avons des ordinateurs! Fou.