Comment rendre mon application Web apatride tout en faisant quelque chose d'utile?

Question

Je l'ai vu ce conseil ...

idéalement le web devrait suivre le principe de repos et être tout à fait sans état. Par conséquent, une seule URL devrait identifier une seule ressource, sans avoir à conserver l'historique de navigation de chaque utilisateur.

... et j'ai lu la page Wikipedia http://en.wikipedia.org/wiki/REST et ça sonne vraiment bien, mais je ne comprends pas comment l'implémenter. Je travaille dans ASP .NET Webforms NOT MVC.

Par exemple, dans l'application que je suis sur le point de construire - je besoin de mon utilisateur de se connecter avant de les permet pas d'agir. Il y a deux ou trois obstacles à franchir avant qu'ils ne soient autorisés à faire beaucoup de choses utiles - par exemple, accepter les T et les C et confirmer que leurs détails de base sont inchangés. Enfin, ils sont autorisés à faire quelque chose qu'ils veulent vraiment comme BuyAProduct!

Il me semble (je viens du monde FORTEMENT ÉTONNANT du client riche) que j'ai besoin d'un état pour enregistrer ce qu'ils ont fait et en déduire ce qu'ils sont autorisés à faire. Je ne vois pas comment je peux les soutenir (disons) en mettant en signet l'URI BuyAProduct. Quand ils arrivent au signet, comment puis-je savoir s'ils se sont connectés et s'ils ont accepté les T et C et s'ils ont scrupuleusement vérifié leurs détails de base? J'adore l'idée que l'application soit apatride, en partie parce qu'elle semble résoudre complètement le problème de "Que diable dois-je faire lorsque l'utilisateur clique sur les boutons Précédent et Suivant?" Je ne vois pas comment je peux encore le faire fonctionner correctement. Je sens qu'il me manque quelque chose de vraiment fondamental à ce sujet.

Answer 1

Le conseil ne suggère pas que l'application devrait être sans état - il suggère que les ressources de l'application soient apatrides. C'est-à-dire qu'une page appelée "www.monsite.com/resources/123" représentera toujours la même ressource, quel que soit l'utilisateur qui y accède ou qu'il soit connecté ou non.

(Le fait que vous pourriez refuser l'accès utilisateur non connecté est une question distincte - le point est que l'Uri lui-même ne repose pas sur des données spécifiques à l'utilisateur de travailler.)

Par exemple , les types de sites qui enfreignent cette règle sont ceux où vous accédez à une page de produit, envoyez l'Uri à votre ami, et en cliquant dessus, ils voient un message du type "Je suis désolé, votre session a expiré" ou "Ce produit n'existe pas" ou similaire. La raison en est que l'Uri inclut quelque chose de spécifique à la session de l'utilisateur sur le site, et si un autre utilisateur essaie d'utiliser le lien (ou le même utilisateur ultérieurement), il n'est plus valide.

Ainsi, vous aurez toujours besoin encore une certaine forme d'Etat pour votre application, mais où l'Etat est mis en œuvre est le facteur important.

Un espoir qui aide à jeter un peu de lumière!

Answer 2

Si vous voulez faire des formulaires Web, c'est cool. Si vous voulez faire REST c'est cool aussi. Mais s'il vous plaît pour l'amour de tout sacré, s'il vous plaît ne pas essayer d'adhérer aux principes de REST en utilisant des formulaires Web. Juste pour clarifier ce point, je ne crois pas que webforms soit un choix judicieux pour REST parce que le modèle conceptuel sur lequel WebForms est basé est celui où vous absentez le web. Il a été conçu pour émuler le modèle de développement VB.REST englobe HTTP et la nature distribuée des applications Web. Les deux approches ne sont pas compatibles.

Answer 3

Voici la chose: REST est sur les communications avec état sur un protocole sans état. Ce n'est pas que REST soit apatride. WebForms vous permet de conserver l'état entre les demandes. Pourquoi est-ce nécessaire? Il vous permet de trier des éléments d'une liste avec des boutons haut/bas sans avoir à mettre à jour la ressource sous-jacente à chaque clic. Tu n'as pas besoin de ça. Vous pouvez simplement METTRE la représentation de la ressource pour qu'elle semble correcte ou utiliser JavaScript pour éditer votre représentation et ensuite faire un PUT à la fin une fois que vous êtes satisfait. (Notez que j'ai utilisé PUT, pas POST. Ce que vous faites est de remplacer la représentation pour que les futurs GET récupèrent le bon état.)

WebForms utilise POST pour tout. Vous ne devriez POSTER à une URL que lorsque vous créez un nouvel élément et ne savez pas où il va vivre. Si vous connaissez son URL, vous devez utiliser PUT pour créer ou remplacer. Si vous avez besoin d'étapes intermédiaires pour, disons, un panier, vous devez créer des représentations de ressources pour ces étapes intermédiaires. Votre navigateur et votre serveur communiquent en transmettant des représentations complètes entre eux. C'est un simple message de demande/réponse.

WebForms n'encourage pas cela. Vous pouvez construire des systèmes RESTful dans WebForms, mais le modèle par défaut vous en éloignera vers une approche RPC. Je peux penser à deux façons autour de ceci: Front Controller (auquel cas vous devriez vraiment considérer MVC) ou en utilisant des fichiers .ashx pour presque tout. Le modèle Postback efface à peu près tout espoir réel de faire du vrai REST avec de vrais WebForms/.aspx (c'est-à-dire que PUT et DELETE sont toujours des POST et échouent donc dans le modèle REST).

Answer 4

Un cookie semble être la réponse à votre question. Vous pouvez utiliser le fournisseur d'authentification .net qui va définir un cookie, que votre application peut vérifier et exiger la présence de si elles veulent acheter quelque chose.

La chose que vous voulez essayer et éviter est de garder une représentation d'état d'entre eux sur le serveur, aka cookie de session. Cela rendra la mise à l'échelle plus difficile.

Answer 5

Il est acceptable de conserver l'état des ressources. La "prohibition sans état" se réfère simplement à l'état de la session.

Voici un extrait de Roy Fielding's seminal REST derivation:

Nous ajoutons ensuite une contrainte à l'interaction client-serveur: le style communication doit être sans état dans la nature, comme dans le -client sans état serveur (CSS) de Section 3.4.3 (Figure 5-3), de sorte que chaque requête du client au serveur doit contenir toutes les informations nécessaires pour comprendre la demande, et ne peut pas prendre l'avantage de tout contexte stocké sur le serveur. L'état de la session est donc entièrement conservé sur le client.