Si les applications de repos sont censés pour être apatride, comment gérez-vous les séances ?

Question

Je suis dans le besoin de quelques éclaircissements. J'ai lu sur le REPOS, et la construction Reposant applications. Selon wikipedia, le REPOS lui-même est défini pour être Representational State Transfer. Par conséquent, je ne comprends pas tout ce apatrides gobbledeygook que tout le monde garde en crachant.

De wikipedia:

À un moment donné, un client peut être soit dans la transition entre les états de l'application ou "au repos". Un client dans un état de repos est capable d'interagir avec son utilisateur, mais ne crée pas de charge et consomme pas par client de stockage sur l'ensemble des serveurs ou sur le réseau.

Sont-ils simplement dit de ne pas utiliser de session/l'application niveau de la banque de données???

Je reçois un objectif de REPOS est de faire de l'URI d'accès cohérente et accessible, par exemple, au lieu de cacher les demandes de pagination à l'intérieur des postes, rendant le numéro de page d'une requête d'une partie de l'OBTENIR URI. Fait sens pour moi. Mais il me semble qu'il est juste d'aller à la mer en disant que non par le client de données (données de session) doivent jamais être stockées côté serveur.

Que faire si j'ai eu une file d'attente de messages, et mon envie de lire les messages, mais comme il les a lus, a voulu bloquer certains expéditeurs des messages provenant de la durée de sa session? Ne serait-il pas logique de les stocker dans un endroit sur le côté serveur, et le serveur seulement envoyer des messages (ou ID de message) qui n'ont pas été bloqué par l'utilisateur?

Dois-je vraiment envoyer l'intégralité de la liste des expéditeurs de messages pour bloquer à chaque fois que je demande la liste des nouveaux messages? La liste des messages pertinents à moi ne serait pas/ne devrait même pas être mis à disposition du public des ressources, en premier lieu..

Encore une fois, juste pour essayer de comprendre cela. Quelqu'un merci de le préciser.

Mise à jour:

J'ai trouvé un débordement de pile question qui a une réponse qui n'est pas tout à fait obtenir de moi tout le chemin là: http://stackoverflow.com/questions/2641901/how-to-manage-state-in-rest qui dit que le client de l'état qui est important devraient tous être transférés sur chaque demande.... Ugg.. semble comme beaucoup de frais généraux... c'Est bon??

Answer 1

Par apatrides cela signifie que le serveur web n'enregistre pas de l'état sur le client. Cela n'empêche pas les autres services que le serveur web parle de maintenir l'état sur les affaires objets, pas sur les clients de l'état de la connexion. Les clients de l'état ne doivent pas être stockées sur le serveur, mais passé autour de tout le monde qui en a besoin. C'est là que le SAINT en RESTE vient de, de Transfert de l'État. Vous le transfert de l'état au lieu d'avoir le serveur de les stocker. C'est le seul moyen à l'échelle de millions d'utilisateurs.

La charge de la gestion de session est amorti sur tous les clients, aux clients de stocker leur état de session et les serveurs peuvent service d'un ordre de grandeur ou plus de clients dans un apatride de la mode.

Answer 2

L'apatridie signifie que chaque requête HTTP qui se passe dans un isolement complet. Lorsque le client fait une requête HTTP, il comprend toutes les informations nécessaires pour le serveur pour répondre à cette demande. Le serveur ne jamais s'appuie sur des informations provenant de précédentes demandes. Si cette information était importante, le client aurait envoyé des il de nouveau dans cette demande. L'apatridie apporte également de nouvelles fonctionnalités. Il est plus facile de distribuer un apatride en application sur les serveurs à charge équilibrée. D'un apatride en application est également facile à mettre en cache.

Il existe en fait deux sortes d'état. L'État de l'Application qui vit sur le client et des Ressources de l'État qui vit sur le serveur.

Un service web seulement besoin de soins au sujet de votre état de l'application lorsque vous avez fait une demande. Le reste du temps, il ne sait même pas que vous existez. Cela signifie que chaque fois qu'un client fait une demande, il doit inclure tous les états de l'application, le serveur devra traiter.

Des ressources de l'état est le même pour chaque client, et sa place est sur le serveur. Lorsque vous téléchargez une image à un serveur, vous créez une nouvelle ressource: la nouvelle image a sa propre URI et peut être la cible de toutes les demandes futures. Vous pouvez extraire, modifier, et supprimer cette ressource via HTTP.

Espérons que cela aide à différencier ce que l'apatridie et de divers états.

Answer 3

Sont-ils simplement dit de ne pas utiliser de session/l'application niveau de la banque de données???

Pas de. Ils ne sont pas en disant que dans un moyen trivial.

Ils disent de ne pas définir une "session". Ne vous connectez pas. Ne pas déconnecter. Fournir des informations d'identification avec la demande. Chaque demande est le seul.

Vous avez encore des magasins de données. Vous avez encore d'authentification et d'autorisation. Vous ne perdez pas de temps à l'établissement de sessions et le maintien de l'état de la session.

Le point est que chaque demande (a) représente complètement seul et (b) peut être trivialement d'élevage à un géant parallèle batterie de serveurs sans travail effectif. Apache ou Squid peut passer Reposant demandes autour de aveuglément et avec succès.

Que faire si j'ai eu une file d'attente de messages, et mon envie de lire les messages, mais comme il les a lus, a voulu bloquer certains expéditeurs des messages provenant de la durée de sa session?

Si l'utilisateur veut un filtre, il suffit ensuite de fournir le filtre sur chaque demande.

Ne serait-il pas logique de ... demander au serveur d'envoyer des messages uniquement (ou ID de message) qui n'ont pas été bloqué par l'utilisateur?

Oui. Fournir le filtre dans le repos URI de la requête.

Dois-je vraiment envoyer l'intégralité de la liste des expéditeurs de messages pour bloquer à chaque fois que je demande la liste des nouveaux messages?

Oui. Grand comment cette "liste des expéditeurs de messages de bloc"? Une courte liste de PK?

Une demande peut être très grand. Si nécessaire, vous pouvez essayer une requête POST, même si elle ressemble à un genre de requête.

Answer 4

Vous avez absolument raison, en soutenant complètement apatrides interactions avec le serveur met une charge supplémentaire sur le serveur. Cependant, si vous envisagez de mise à l'échelle d'une application, la puissance de calcul de la clientèle est directement proportionnel au nombre de clients. Donc mise à l'échelle à un grand nombre de clients est beaucoup plus faisable.

Dès que vous mettez un petit peu de responsabilité sur le serveur pour gérer certaines informations relatives à un client spécifique les interactions de l', cette charge peut croître rapidement à consommer le serveur.

C'est un compromis.

Answer 5

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

Des séances dans le sens traditionnel de garder l'utilisateur de l'état dans l'application à l'intérieur du serveur. Cela peut être la page en cours dans un flux ou ce qui a déjà été saisis mais pas persisté jusqu'à la principale base de données.

La raison de ce besoin a été l'absence de normes sur le côté client afin d'assurer le maintien de l'état sans faire spécifique au client (c'est à dire au navigateur) d'applications ou de plugins.

HTML5 et XML-Tête de la Demande au fil du temps normalisé à la notion de stocker des données complexes, y compris l'état de l'application de manière standard sur le client (navigateur) sans avoir recours à un va-et-vient entre le serveur.

Utilisation générale des services REST

RESTE services sont appelés généralement quand il y a une opération qui doit être effectuée ou si il a besoin de récupérer des données.

RESTE services sont destinés à être appelé par l'application côté client et non pas directement aux utilisateurs finaux.

L'authentification

Pour toute demande au serveur, la partie de la requête doit contenir le jeton d'autorisation. La façon dont il est mis en œuvre est spécifique à l'application, mais en général, est une BASIC ou CERTIFICATE formulaire d'authentification.

Authentification basée sur des formulaires n'est pas utilisé par les services REST. Toutefois, comme indiqué ci-dessus RESTE services ne sont pas destinés à être appelés par l'utilisateur, mais par l'application. L'application doit gérer à obtenir le jeton d'authentification. Dans mon cas, j'ai utilisé des biscuits avec JASPIC avec OAuth 2.0 pour vous connecter à Google pour l'authentification et simple Authentification HTTP pour le test automatisé. J'ai aussi utilisé l'en-Tête HTTP d'authentification via JASPIC pour tests locaux (bien que la même approche peut être effectuée dans SiteMinder)

Par ces exemples, l'authentification est gérée sur le côté client (si SiteMinder ou Google serait de stocker la session d'authentification sur leur fin), il n'y a rien qui peut être fait à propos de cet état, mais il ne fait pas partie du RESTE de l'application de service.

Les demandes de recherche

Les demandes de recherche dans le REPOS sont GET des opérations où une ressource est demandée et est mis en cache. Il n'est pas nécessaire pour les sessions de serveur parce que la demande a tout ce dont il aurait besoin pour récupérer les données: l'authentification et de l'URI.

Des scripts de Transaction

Comme indiqué ci-dessus, la partie cliente de l'application elle-même appelle le RESTE des services d'authentification qu'il gère sur le côté client.

Ce que cela signifie pour les services REST [si fait correctement] est de prendre une seule demande pour le RESTE de serveur contiendra tout ce qui est nécessaire pour une seule opération de l'utilisateur qui fait tout ce qui est nécessaire en une seule transaction, une Transaction Script est ce que le modèle est appelé.

Ceci est fait grâce à un POST demande habituellement, mais d'autres tels que l' PUT peut également être utilisé.

Beaucoup d'exemples inventées de REPOS (je me suis fait cela), a tenté de suivre autant de ce qui a été défini dans le protocole HTTP, une fois que j'ai décidé d'être plus pragmatique et à gauche pour GET et POST seulement. L' POST méthode ne même pas avoir à mettre en œuvre la POSTE-RÉACHEMINEMENT-GET modèle.

Peu importe si, comme je l'avais mentionné ci-dessus, l'application côté client sera l'un appelant le service et qu'il va appeler l' POST de la demande avec toutes les données lorsqu'il en a besoin (pas tout le temps). Cela empêche constante des demandes vers le serveur.

D'interrogation

Bien que le REPOS peut être utilisé pour l'interrogation ainsi, je ne vous le recommande pas, sauf si vous avez de l'utiliser en raison de la compatibilité du navigateur. Pour cela je voudrais utiliser les WebSockets qui je l'avais conçu une API contrat . Une autre alternative pour les navigateurs plus anciens est CometD.