Comment appliquer des “sessions” dans des services Web RESTful à l’aide de RESTlet?

Je suis nouveau sur les services Web RESTful et RESTlet. NOUS n’avons d’expérience que dans la création d’applications Web basées sur des servlets (Servlet / JSP sur JBoss / Apache). Nous construisons maintenant une application basée sur RESTlet dans laquelle l’API côté serveur serait utilisée par deux types de clients: le Web utilisant un navigateur et le swing basé sur un ordinateur de bureau.

Ce que je comprends, c’est que, conformément aux concepts REST, le serveur ne peut pas gérer les sessions pour améliorer l’évolutivité et quelques autres raisons. B) chaque demande du client doit être autonome.

Maintenant, je suis vraiment confus de savoir comment y parvenir. Supposons que nous prenions une simple application de panier.

Étape 1) Le client envoie la demande d’authentification, le serveur s’authentifie et le serveur répond OK.

Étape 2) Le client envoie une demande pour append un article au panier. Le serveur répond OK.

Étape 3) Le client envoie une autre demande pour append le deuxième article à la carte d’achat. Le serveur répond OK.

Normalement, dans une application Web normale, une session est créée à l’étape 1 sur le serveur. À partir de ce moment, toutes les demandes relatives à ce client sont automatiquement associées à la même session et nous stockons l’état de la session (panier dans ce cas) dans session et récupérez-le / mettez-le à jour avec les demandes suivantes du client.

Maintenant, dans le scénario ci-dessus:

1) comment authentifier et autoriser le client aux étapes 2 et 3 si aucune session n’est maintenue sur le serveur?

2) Le client doit-il envoyer des informations supplémentaires à chaque demande?

3) Comment récupérer le panier spécifique au client à l’étape 3?

4) Le client doit-il envoyer le panier créé / retourné par le serveur à l’étape 2 à l’étape 3?

De toute évidence, il s’agit du cas d’utilisation le plus simple. Tous ceux qui développent des services Web RESTful doivent donc concevoir leur application pour gérer cela. Quel est le moyen le plus courant et le plus courant de gérer la gestion de session, l’authentification et l’autorisation dans les services Web RESTful à l’aide de RESTLet? Si nous devons conserver le cache côté serveur avec les données du client, en quoi est-ce différent du serveur qui maintient les sessions en notre nom?

Merci d’avance, Deep

1) comment authentifier et autoriser le client aux étapes 2 et 3 si aucune session n’est maintenue sur le serveur?

2) Le client doit-il envoyer des informations supplémentaires à chaque demande?

Oui. Vous devez envoyer des données d’authentification / autorisation à chaque demande. C’est ce qui empêchera le serveur de “se souvenir” de qui vous êtes (c.-à-d. Serveur sans état, pas de sessions)

3) Comment récupérer le panier spécifique au client à l’étape 3?

Posons une autre question: que se passera-t-il si le serveur redémarre? Voulez-vous que toutes les données du panier soient perdues? Probablement pas. Cela implique que vous devez le stocker quelque part pour pouvoir survivre à un redémarrage. Impliquant un stockage persistant. Pourrait être sur le serveur ou le client …

… maintenant, que se passe-t-il si votre client redémarre? Vous pouvez choisir de créer une “ressource” dans le panier pour cet utilisateur à l’aide d’une demande POST (lorsque l’utilisateur ajoute le premier élément) ou de le créer dès l’instant où le client se connecte (gaspillage). Ensuite, vous continuez de mettre à jour le panier avec PUT / DELETE et vous le récupérez avec GET.

Devrait-il être dans la firebase database? Peut-être, ça dépend si c’est comme ça que vous voulez. S’il doit être persistant, c’est un bon endroit pour le conserver afin qu’il puisse survivre à un redémarrage.

Alors, comment recevoir un panier spécifique au client? Eh bien, vous venez d’envoyer une demande GET pour la ressource !!! C’est tout! Le premier POST créera une ressource à une URL appropriée et vous pourrez ensuite l’utiliser.

Les services Web reposants ont également des URL reposantes, ce qui en fait un élément clé de la conception.

4) Le client doit-il envoyer le panier créé / retourné par le serveur à l’étape 2 à l’étape 3?

Non, comme mentionné ci-dessus. Mais si vous utilisez des cookies ou LocalStorage ou d’autres informations côté client, alors peut-être que vous le faites.

De toute évidence, il s’agit du cas d’utilisation le plus simple. Tous ceux qui développent des services Web RESTful doivent donc concevoir leur application pour gérer cela. Quel est le moyen le plus courant et le plus courant de gérer la gestion de session, l’authentification et l’autorisation dans les services Web RESTful à l’aide de RESTLet?

Oui. C’est simple mais il faut un certain temps pour penser en termes de «ressources» plutôt que de «services». Dans une conception reposante, tout est (ou peut être) une ressource, y compris des transactions, des paniers, etc.

Cependant, l’autorisation / authentification fait partie du paquet de requête http et est envoyée avec chaque requête. Je vous suggère de lire sur ceux-ci.

Si nous devons conserver le cache côté serveur avec les données du client, en quoi est-ce différent du serveur qui maintient les sessions en notre nom?

Grande différence! Mettez-vous en cache pour des performances ou maintenez-vous une session? Si le système redémarre, votre système fonctionnera-t-il de manière transparente sur un cache vide? Si oui, vous mettez en cache pour la performance, sinon vous maintenez l’état.

Je vous suggère fortement de lire les services Web RESTful de Richardson & Ruby pour clarifier les concepts ci-dessus et mieux comprendre comment les services reposants sont conçus. Il faut s’y habituer.