L’explication fondamentale est la suivante:

Aucun état de session client sur le serveur.

Par état sans état, cela signifie que le serveur ne stocke aucun état sur la session client du côté serveur.

La session client est stockée sur le client. Le serveur est sans état signifie que chaque serveur peut desservir n’importe quel client à tout moment, il n’y a pas d’ affinité de session ou de sessions persistantes . Les informations de session pertinentes sont stockées sur le client et transmises au serveur si nécessaire.

Cela n’empêche pas les autres services auxquels le serveur Web s’adresse de conserver l’état des objects métier tels que les paniers, mais pas l’état actuel de l’application / de la session du client.

L’état de l’application du client ne doit jamais être stocké sur le serveur, mais transmis du client à tous les endroits qui en ont besoin.

C’est de là que vient le ST dans REST , State Transfer . Vous transférez l’état au lieu que le serveur le stocke. C’est le seul moyen de s’adapter à des millions d’utilisateurs simultanés. Si ce n’est que pour des millions de sessions, ce sont des millions de sessions.

Le chargement de la gestion de session est amorti sur tous les clients, les clients stockent leur état de session et les serveurs peuvent traiter plusieurs ordres de grandeur ou davantage de clients de manière sans état.

Même pour un service qui, selon vous, ne nécessitera que des dizaines d’utilisateurs sur des milliers d’utilisateurs simultanés, vous devez quand même rendre votre service sans état. Des dizaines de milliers de personnes sont encore des dizaines de milliers et des coûts en temps et en espace seront associés.

Stateless est la manière dont le protocole HTTP et le Web ont été conçus pour fonctionner et est une implémentation plus simple. Vous disposez d’un chemin de code unique au lieu d’un tas de logique côté serveur pour maintenir un état de session important.

Il existe des principes de mise en œuvre très basiques:

Ce sont des principes et non des implémentations, la manière dont vous respectez ces principes peut varier.

En résumé, les cinq principes clés sont les suivants:

1. Donner à chaque «chose» un identifiant
2. Lier les choses ensemble
3. Utiliser des méthodes standard
4. Ressources à représentations multiples
5. Communiquer apasortingde

Il n’y a rien sur l’authentification ou l’autorisation dans la dissertation REST.

Parce qu’il n’y a rien de différent de l’authentification d’une requête RESTful par une autre qui ne l’est pas. L’authentification n’est pas pertinente pour la discussion RESTful.

Expliquer comment créer une application sans état pour vos besoins particuliers est trop large pour StackOverflow.

La mise en œuvre de l’authentification et de l’autorisation dans le cadre de REST est encore plus étendue et diverses approches de la mise en œuvre sont expliquées en détail sur Internet en général.

Les commentaires demandant de l’aide / des informations à ce sujet seront / devraient juste être signalés comme étant inutiles .

L’apasortingdie signifie que chaque requête HTTP se produit dans un isolement complet. Lorsque le client effectue une requête HTTP, il inclut toutes les informations nécessaires au serveur pour répondre à cette demande. Le serveur ne s’appuie jamais sur des informations provenant de requêtes précédentes. Si cette information était importante, le client l’aurait renvoyé dans cette demande. L’apasortingdie apporte également de nouvelles fonctionnalités. Il est plus facile de dissortingbuer une application sans état sur des serveurs à charge équilibrée. Une application sans état est également facile à mettre en cache.

Il y a en fait deux sortes d’états. Application Etat qui réside sur le client et l’état des ressources qui réside sur le serveur.

Un service Web doit uniquement prendre en compte l’état de votre application lorsque vous effectuez une demande. Le rest du temps, il ne sait même pas que tu existes. Cela signifie que chaque fois qu’un client effectue une demande, il doit inclure tous les états de l’application dont le serveur aura besoin pour le traiter.

L’état de la ressource est le même pour chaque client et sa place est correcte sur le serveur. Lorsque vous téléchargez une image sur un serveur, vous créez une nouvelle ressource: la nouvelle image possède son propre URI et peut être la cible de futures requêtes. Vous pouvez extraire, modifier et supprimer cette ressource via HTTP.

J’espère que cela aide à différencier ce que signifient l’apasortingdie et les différents états.

Sont-ils juste en train de dire: n’utilisez pas de stockage de données au niveau session / application?

Non, ils ne le disent pas de manière sortingviale.

Ils disent ne pas définir une “session”. Ne vous connectez pas Ne pas déconnecter Fournissez les informations d’identification avec la demande. Chaque demande est unique.

Vous avez toujours des magasins de données. Vous avez toujours une authentification et une autorisation. Vous ne perdez simplement pas de temps à établir des sessions et à maintenir l’état de la session.

Le fait est que chaque demande (a) est complètement isolée et (b) peut être sortingvialement transformée en une ferme de serveurs parallèle géante sans travail réel. Apache ou Squid peuvent transmettre les requêtes RESTful à l’aveuglette et avec succès.

Et si j’avais une queue de messages et que mon utilisateur voulait lire les messages, mais qu’il les lisait, il voulait bloquer certains messages des expéditeurs pendant la durée de sa session?

Si l’utilisateur souhaite un filtre, fournissez simplement le filtre sur chaque requête.

Ne serait-il pas logique de … le serveur envoie-t-il uniquement des messages (ou des ID de message) qui n’ont pas été bloqués par l’utilisateur?

Oui. Fournissez le filtre dans la demande d’URI RESTful.

Dois-je vraiment envoyer la liste complète des expéditeurs de messages à bloquer chaque fois que je demande la nouvelle liste de messages?

Oui. Quelle peut être la taille de cette “liste des expéditeurs de messages à bloquer”? Une courte liste de PK?

Une requête GET peut être très importante. Si nécessaire, vous pouvez essayer une requête POST même si cela ressemble à une sorte de requête.

Vous avez absolument raison, la prise en charge d’interactions complètement sans état avec le serveur impose un fardeau supplémentaire au client. Toutefois, si vous envisagez de mettre à l’échelle une application, la puissance de calcul des clients est directement proportionnelle au nombre de clients. Par conséquent, le passage à un nombre élevé de clients est beaucoup plus faisable.

Dès que vous mettez un peu de responsabilité sur le serveur pour gérer certaines informations relatives aux interactions d’un client spécifique, cette charge peut rapidement augmenter pour consumr le serveur.

C’est un compromis.

Vue historique de la gestion de l’état de l’application utilisateur

Les sessions au sens traditionnel conservent l’état de l’utilisateur dans l’application à l’intérieur du serveur. Il peut s’agir de la page en cours dans un stream ou de ce qui a déjà été saisi, mais pas encore conservé dans la firebase database principale.

La raison de ce besoin était le manque de normes du côté client pour maintenir efficacement l’état sans rendre les applications ou les plug-ins spécifiques au client (c.-à-d. Spécifiques au navigateur).

La demande d’en-tête HTML5 et XML a standardisé au fil du temps la notion de stockage de données complexes, y compris l’ état des applications, de manière standard du côté client (c.-à-d. Navigateur) sans avoir à faire de va-et-vient entre les serveurs.

Utilisation générale des services REST

Les services REST sont généralement appelés lorsqu’il y a une transaction à effectuer ou qu’il faut extraire des données.

Les services REST doivent être appelés par l’application côté client et non directement par l’utilisateur final.

Authentification

Pour toute demande adressée au serveur, une partie de la demande doit contenir le jeton d’autorisation. La manière dont il est implémenté est spécifique à l’application, mais en général, il s’agit d’une forme d’authentification BASIC ou CERTIFICATE .

L’authentification basée sur les formulaires n’est pas utilisée par les services REST. Cependant, comme indiqué ci-dessus, les services REST ne sont pas destinés à être appelés par l’utilisateur, mais par l’application. L’application doit gérer l’obtention du jeton d’authentification. Dans mon cas, j’ai utilisé des cookies avec JASPIC avec OAuth 2.0 pour me connecter à Google pour l’authentification et une authentification HTTP simple pour les tests automatisés. J’ai également utilisé l’ authentification par en-tête HTTP via JASPIC pour les tests locaux également (bien que la même approche puisse être effectuée dans SiteMinder)

Selon ces exemples, l’authentification est gérée du côté client (bien que SiteMinder ou Google stocke la session d’authentification à sa fin), il n’y a rien à faire concernant cet état, mais cela ne fait pas partie de l’application de service REST.

Demandes de récupération

Les requêtes de récupération dans REST sont des opérations GET lorsqu’une ressource spécifique est demandée et peut être mise en cache. Il n’y a pas besoin de sessions serveur car la requête a tout ce qu’il faut pour récupérer les données: l’authentification et l’URI.

Scripts de transaction

Comme indiqué ci-dessus, l’application côté client appelle elle-même les services REST avec l’authentification qu’elle gère également du côté client.

Ce que cela signifie pour les services REST [si c’est fait correctement] consiste à envoyer une requête unique au serveur REST qui contiendra tout ce qui est nécessaire pour une opération d’utilisateur unique qui effectue tout ce qui est nécessaire dans une transaction unique. est appelé.

Cela se fait généralement via une requête POST , mais d’autres, comme PUT peuvent également être utilisées.

Beaucoup d’exemples de REST (j’ai moi-même fait cela) ont essayé de suivre autant de ce qui a été défini dans le protocole HTTP, après avoir passé en revue que j’ai décidé d’être plus pragmatique et de le laisser à GET et POST seulement . La méthode POST n’a même pas à implémenter le modèle POST-REDIRECT-GET.

Quoi qu’il en soit, comme je l’ai noté ci-dessus, l’application côté client sera celle qui appellera le service et elle appellera uniquement la demande POST avec toutes les données nécessaires (pas à chaque fois). Cela empêche les requêtes constantes au serveur.

Vote

Bien que REST puisse également être utilisé pour les interrogations, je ne le recommanderai que si vous devez l’utiliser à cause de la compatibilité du navigateur. Pour cela, j’utiliserais WebSockets pour lequel j’avais également conçu un contrat API . CometD est une autre alternative pour les navigateurs plus anciens.

REST est très abstrait. Cela aide d’avoir de bons exemples simples et réels.

Prenons par exemple toutes les principales applications de médias sociaux – Tumblr, Instagram, Facebook et Twitter. Ils ont tous une vue à défilement permanent où plus vous défilez vers le bas, plus vous voyez de contenu, de plus en plus loin dans le temps. Cependant, nous avons tous vécu ce moment où vous perdez où vous avez fait défiler, et l’application vous remet au sumt. Comme si vous quittiez l’application, alors lorsque vous la rouvrez, vous êtes de nouveau au sumt.

La raison en est que le serveur n’a pas enregistré votre état de session. Malheureusement, votre position de défilement était juste stockée dans la RAM sur le client.

Heureusement, vous n’êtes pas obligé de vous reconnecter lorsque vous vous reconnectez, mais uniquement parce que votre certificate de connexion également stocké côté client n’a pas expiré. Supprimez et réinstallez l’application et vous devrez vous reconnecter car le serveur n’a pas associé votre adresse IP à votre session.

Vous n’avez pas de session de connexion sur le serveur, car elles sont conformes à REST.

Maintenant, les exemples ci-dessus n’impliquent pas du tout de navigateur Web, mais les applications communiquent via HTTPS avec leurs serveurs hôtes. Ce que je veux dire, c’est que REST n’a pas à impliquer les cookies et les navigateurs, etc. Il existe différents moyens de stocker l’état de session côté client.

Mais parlons un peu des navigateurs Web, car cela soulève un autre avantage majeur de REST dont personne ne parle ici.

Si le serveur a essayé de stocker l’état de la session, comment est-il censé identifier chaque client individuel?

Il ne pouvait pas utiliser leur adresse IP, car de nombreuses personnes pouvaient utiliser cette même adresse sur un routeur partagé. Alors comment, alors?

Il ne peut pas utiliser l’adresse MAC pour de nombreuses raisons, notamment parce que vous pouvez être connecté à plusieurs comptes Facebook différents simultanément sur différents navigateurs et à l’application. Un navigateur peut facilement prétendre être un autre, et les adresses MAC sont tout aussi faciles à usurper.

Si le serveur doit stocker un état côté client pour vous identifier, il doit le stocker dans la mémoire RAM plus longtemps que le temps nécessaire au traitement de vos demandes, sinon il doit mettre en cache ces données. Les serveurs ont des quantités limitées de RAM et de cache, sans parler de la vitesse du processeur. L’état côté serveur ajoute les trois, de manière exponentielle. De plus, si le serveur doit stocker des informations sur vos sessions, il doit les stocker séparément pour chaque navigateur et application avec lesquels vous êtes actuellement connecté, ainsi que pour chaque périphérique que vous utilisez.

Donc, j’espère que vous voyez maintenant pourquoi REST est si important pour l’évolutivité. J’espère que vous pouvez commencer à comprendre pourquoi l’état de session côté serveur est à l’évolutivité du serveur, ce que les enclumes soudées sont à l’accélération de la voiture.

On se confond en pensant que “état” se réfère, par exemple, aux informations stockées dans une firebase database. Non, il fait référence à toute information devant figurer dans la mémoire vive du serveur lorsque vous l’utilisez.

Stateless signifie que l’état du service ne persiste pas entre les demandes et réponses suivantes. Chaque demande comporte ses propres identifiants d’utilisateur et est authentifiée individuellement. Mais dans chaque état, chaque demande est connue de toute demande préalable. Toutes les requêtes avec état sont orientées vers la session, c.-à-d. Que chaque demande doit connaître et conserver les modifications apscopes dans les demandes précédentes.

L’application bancaire est un exemple d’application avec état. Où l’utilisateur se connecte d’abord, puis effectue la transaction et se déconnecte. Si, après la déconnexion, l’utilisateur tente d’effectuer la transaction, il ne pourra pas le faire.

Oui, le protocole http est essentiellement un protocole sans état, mais pour le rendre dynamic, nous utilisons des cookies HTTP. Donc, est SOAP par défaut. Mais cela peut être aussi dynamic, dépend du cadre que vous utilisez.

HTTP est sans état mais nous pouvons toujours maintenir la session dans notre application Java en utilisant un mécanisme de suivi de session différent.

Oui, nous pouvons également maintenir la session dans le service Web, que ce soit REST ou SOAP. Il peut être implémenté en utilisant une bibliothèque tierce ou que vous pouvez implémenter par nos propres moyens.

Tiré de http://gopaldas.org/webservices/soap/webservice-is-stateful-or-stateless-rest-soap

Je vois que le problème fondamental ici est de mélanger Session avec State . Et tandis que REST spécifie que vous ne devez PAS stocker l’ état sur le serveur, rien ne vous empêche de stocker une session utilisateur.

La gestion de l’ état sur le serveur signifie que votre serveur sait exactement ce que fait le client (quelle page ils consultent dans quelle section de l’application). Et c’est ce que vous ne devriez pas avoir à faire.

Je suis d’accord avec les autres personnes pour dire que vous devez conserver le stockage de la session à une taille minimale; et bien que ce soit le sens commun, cela dépend aussi de l’application. Donc, en bref, vous pouvez toujours conserver une session avec des données mises en cache pour gérer les demandes avec moins de charge sur le serveur et gérer l’authentification en fournissant un jeton d’authentification / access temporaire à utiliser par le client. Chaque fois que la session / le jeton a expiré, créez-en un nouveau et demandez au client de l’utiliser.

Quelqu’un pourrait prétendre que le client devrait mieux générer le jeton. Je dis que cela fonctionne dans les deux sens, cela dépend de l’application et de qui va travailler avec l’API.

Garder également des données de session sensibles sur le serveur devrait être la bonne façon de faire. Vous ne pouvez pas faire confiance au client pour conserver son panier (par exemple) qui contient un champ nommé “isFreeGift”. Ces informations doivent être conservées sur le serveur.

Le lien vidéo fourni par Santanu Dey dans sa réponse est utile. Regardez-le si vous ne l’avez pas fait.

Juste une note: il semble que toutes les réponses déjà données semblent ignorer le fait que certaines opérations pourraient causer une lourde charge sur le serveur. Cela est pertinent en termes de consommation d’énergie, de consommation de matériel et de coût (pour les serveurs loués par cycle CPU). Un bon développeur ne devrait pas être paresseux dans l’optimisation de son application, même si l’opération peut être effectuée très rapidement sur un processeur moderne sur un serveur loué pour lequel il ne paie pas sa facture d’élecsortingcité et de maintenance.

Althoght la question a quelques années, j’espère que ma réponse sera toujours utile.

Regardez cette présentation.

http://youtu.be/MRxTP-rQ-S8

Selon ce modèle, créer des ressources transitoires pour gérer l’état si nécessaire. Évitez les sessions explicites.

La principale différence entre stateless vs stateful est la transmission des données au serveur à chaque fois. En cas d’apasortingdie, le client doit fournir toutes les informations, il faudra donc passer beaucoup de parameters dans chaque requête. Dans Stateful, le cliet transmet ces parameters une fois et ils sont maintenus par le serveur jusqu’à ce qu’ils soient modifiés à nouveau par le client.

IMO, API devrait être sans état, ce qui permet de faire évoluer très rapidement.

Vous devez gérer la session client du côté client. Cela signifie que vous devez envoyer des données d’authentification à chaque requête et que vous avez probablement, mais pas nécessairement, un cache en mémoire sur le serveur, qui associe les données d’authentification aux informations utilisateur telles que l’identité, les permissions, etc.

Cette contrainte d’apasortingdie REST est très importante. Sans cette contrainte, votre application côté serveur ne sera pas très évolutive car le maintien de chaque session client sera son talon d’Achille .

Le concept entier est différent … Vous n’avez pas besoin de gérer les sessions si vous essayez d’implémenter le protocole RESTFul. Dans ce cas, il est préférable d’effectuer une procédure d’authentification à chaque requête (alors qu’il ya un coût supplémentaire en termes de performances – le hachage de mot de passe serait un bon exemple, pas une grosse affaire…). Si vous utilisez des sessions, comment répartir la charge sur plusieurs serveurs? Je parie que le protocole RESTFul est censé éliminer les sessions – vous n’en avez pas vraiment besoin … C’est pourquoi on l’appelle “sans état”. Les sessions ne sont requirejses que si vous ne pouvez pas stocker autre chose que des cookies du côté client après qu’un reqest a été fait (prenez comme exemple l’ancien navigateur non compatible Javascript / HTML5). En cas de client RESTFul “complet”, il est généralement prudent de stocker base64(login:password) côté client (en mémoire) jusqu’à ce que l’application soit toujours chargée – l’application est utilisée pour accéder au seul hôte et au cookie ne peut pas être compromis par les scripts tiers …

Je recommande fortement de désactiver l’authentification par cookie pour les services RESTFul … consultez Auth Basic / Digest – cela devrait suffire pour les services basés sur RESTFul.

REST est sans état et ne conserve aucun état entre les requêtes. Les cookies / en-têtes clients sont configurés pour conserver l’état utilisateur comme l’authentification. Le nom d’utilisateur / mot de passe de Say Client est validé par un mécanisme d’authentification tiers. – Une fois que l’utilisateur est authentifié, les en-têtes / cookies arrivent au sharepoint fin de service et l’utilisateur peut s’authentifier. . Maintenant, certaines informations de l’utilisateur comme IP sont soit conservées dans le cache et ensuite, si la requête provient du même IP (adresse mac) pour les ressources listées, l’utilisateur est autorisé. Et le cache est maintenu pendant un certain temps qui est invalidé une fois le temps écoulé. Ainsi, vous pouvez utiliser soit le cache, soit les entrées de la firebase database pour conserver les informations n / b des requêtes.