Comprendre l'Internet sans état [fermé]

Je passe d'un développeur de bureau à un développeur Web et j'ai du mal à comprendre pourquoi HTTP est sans état. Quelles en sont les raisons? De quelles manières un développeur de bureau comme moi peut-il effectuer la transition vers un environnement de développement sans état?

C'est la meilleure explication de l'Internet sans état que j'ai vue:

Comment j'ai expliqué REST  à ma femme
http://www.looah.com/source/view/2284

Épouse: Qui est Roy Fielding?

Ryan: Un gars. Il est intelligent.

Épouse: Oh? Qu'est ce qu'il a fait?

Ryan: Il a aidé à écrire les premiers serveurs Web, puis a fait une tonne de recherches expliquant pourquoi le Web fonctionne comme il le fait. Son nom figure sur la spécification du protocole utilisé pour obtenir les pages des serveurs vers votre navigateur.

Épouse: Comment ça marche?

Ryan: Le Web?

Épouse: Ouais.

Ryan: Hmm. Eh bien, c'est vraiment assez incroyable. Et le plus drôle, c'est que tout cela est très sous-évalué. Le protocole dont je parlais, HTTP, est capable de toutes sortes de choses intéressantes que les gens ignorent pour une raison quelconque.

Épouse: Vous voulez dire http comme le début de ce que je tape dans le navigateur?

Ryan: Ouais. Cette première partie indique au navigateur quel protocole utiliser. Ce truc que vous tapez là-bas est l'une des percées les plus importantes de l'histoire de l'informatique.

Épouse: Pourquoi?

Ryan: Parce qu'il est capable de décrire l'emplacement de quelque chose n'importe où dans le monde, de n'importe où dans le monde. C'est le fondement du web. Vous pouvez y penser comme des coordonnées GPS pour la connaissance et l'information.

Épouse: Pour les pages Web?

Ryan: Pour tout, vraiment. Ce gars, Roy Fielding, il parle beaucoup de ce à quoi ces choses pointent dans cette recherche dont je parlais. Le Web est construit sur un style architectural appelé REST. REST fournit une définition d'une ressource, ce à quoi ces éléments pointent.

Épouse: Une page Web est une ressource?

Ryan: En quelque sorte. Une page Web est une représentation d'une ressource. Les ressources ne sont que des concepts. URL - ces choses que vous tapez dans le navigateur ...

Épouse: Je sais ce qu'est une URL ..

Ryan: Oh, c'est vrai. Ceux-ci indiquent au navigateur qu'il existe un concept quelque part. Un navigateur peut alors aller demander une représentation spécifique du concept. Plus précisément, le navigateur demande la représentation de la page Web du concept.

Épouse: Quels autres types de représentations existe-t-il?

Ryan: En fait, les représentations sont l'une de ces choses qui ne sont pas souvent utilisées. Dans la plupart des cas, une ressource n'a qu'une seule représentation. Mais nous espérons que les représentations seront davantage utilisées à l'avenir, car il y a un tas de nouveaux formats qui apparaissent partout.

Épouse: Comme quoi?

Ryan: Hmm. Eh bien, il y a ce concept que les gens appellent les services Web. Cela signifie beaucoup de choses différentes pour beaucoup de personnes différentes, mais le concept de base est que les machines peuvent utiliser le Web comme les gens.

Épouse: Est-ce un autre truc de robot?

Ryan: Non, pas vraiment. Je ne veux pas dire que les machines seront assises au bureau et navigueront sur le Web. Mais les ordinateurs peuvent utiliser ces mêmes protocoles pour envoyer des messages entre eux. Nous le faisons depuis longtemps, mais aucune des techniques que nous utilisons aujourd'hui ne fonctionne bien lorsque vous devez pouvoir parler à toutes les machines du monde entier.

Épouse: Pourquoi pas?

Ryan: Parce qu'ils n'étaient pas conçus pour être utilisés comme ça. Lorsque Fielding et ses copains ont commencé à construire le Web, pouvoir parler à n'importe quelle machine n'importe où dans le monde était une préoccupation majeure. La plupart des techniques que nous utilisons au travail pour amener les ordinateurs à se parler ne répondaient pas à ces exigences. Vous aviez juste besoin de parler à un petit groupe de machines.

Épouse: Et maintenant tu dois parler à toutes les machines?

Ryan: Oui - et plus encore. Nous devons pouvoir parler à toutes les machines de tout ce qui se trouve sur toutes les autres machines. Nous avons donc besoin d'un moyen pour qu'une machine informe une autre machine d'une ressource qui pourrait se trouver sur une autre machine.

Épouse: Quoi?

Ryan: Disons que tu parles à ta sœur et qu'elle veut emprunter la balayeuse ou quelque chose. Mais vous ne l'avez pas - votre maman l'a. Donc, tu dis à ta sœur de le prendre à ta place. Cela se produit tout le temps dans la vraie vie et cela se produit tout le temps lorsque les machines commencent à parler aussi.

Épouse: Alors, comment les machines se disent-elles où sont les choses?

Ryan: L'URL, bien sûr. Si tout ce dont les machines ont besoin a une URL correspondante, vous avez créé l'équivalent machine d'un nom. Que vous et moi et le reste du monde ayons convenu de parler des noms d'une certaine manière est assez important, hein?

Épouse: Ouais.

Ryan: Les machines n'ont pas de nom universel - c'est pourquoi elles sont nulles. Chaque langage de programmation, base de données ou autre type de système a une manière différente de parler des noms. C'est pourquoi l'URL est si importante. Il permet à tous ces systèmes de se parler les uns des autres.

Épouse: Mais quand je regarde une page Web, je n'y pense pas comme ça.

Ryan: Personne ne le fait. Sauf Fielding et une poignée d'autres personnes. C'est pourquoi les machines sont toujours nulles.

Épouse: Qu'en est-il des verbes, des pronoms et des adjectifs?

Ryan: C'est drôle, tu as demandé parce que c'est un autre gros aspect de REST. Eh bien, les verbes sont de toute façon.

Femme: je plaisantais.

Ryan: C'était une blague drôle mais ce n'est pas du tout une blague. Les verbes sont importants. Il y a un concept puissant dans la programmation et la théorie CS appelé polymorphisme. C'est une façon geek de dire que différents noms peuvent avoir le même verbe appliqué à eux.

Épouse: Je ne comprends pas.

Ryan: Eh bien .. Regardez la table basse. Quels sont les noms? Tasse, plateau, journal, télécommande. Maintenant, quelles sont les choses que vous pouvez faire pour toutes ces choses?

Femme: je ne comprends pas ...

Ryan: Vous pouvez les obtenir, non? Vous pouvez les récupérer. Vous pouvez les renverser. Vous pouvez les brûler. Vous pouvez appliquer ces mêmes verbes exacts à l'un des objets qui s'y trouvent.

Femme: D'accord ... alors?

Ryan: Eh bien, c'est important. Et si au lieu que je puisse vous dire: «prenez la tasse», «prenez le journal» et «prenez la télécommande»; Et si à la place nous devions trouver des verbes différents pour chacun des noms? Je ne pouvais pas utiliser le mot «obtenir» universellement, mais j'ai dû trouver un nouveau mot pour chaque combinaison verbe / nom.

Épouse: Wow! C'est bizarre.

Ryan: Oui, ça l'est. Nos cerveaux sont en quelque sorte assez intelligents pour savoir que les mêmes verbes peuvent être appliqués à de nombreux noms différents. Certains verbes sont plus spécifiques que d'autres et ne s'appliquent qu'à un petit ensemble de noms. Par exemple, je ne peux pas conduire de tasse et je ne peux pas boire de voiture. Mais certains verbes sont presque universels comme GET, PUT et DELETE.

Épouse: Vous ne pouvez pas SUPPRIMER une tasse.

Ryan: D' accord, mais tu peux le jeter. C'était une autre blague, non?

Épouse: Ouais.

Ryan: Quoi qu'il en soit, HTTP - ce protocole créé par Fielding et ses amis - consiste à appliquer des verbes aux noms. Par exemple, lorsque vous accédez à une page Web, le navigateur effectue un HTTP GET sur l'URL que vous saisissez et revient une page Web.

Les pages Web ont généralement des images, non? Ce sont des ressources distinctes. La page Web spécifie simplement les URL des images et le navigateur va et fait plus de GET HTTP sur celles-ci jusqu'à ce que toutes les ressources soient obtenues et que la page Web soit affichée. Mais l'important ici est que des types de noms très différents peuvent être traités de la même manière. Que le nom soit une image, un texte, une vidéo, un mp3, un diaporama, peu importe. Je peux obtenir toutes ces choses de la même manière avec une URL.

Épouse: On dirait que GET est un verbe assez important.

Ryan: Oui. Surtout lorsque vous utilisez un navigateur Web, car les navigateurs sont à peu près juste GET stuff. Ils ne font pas beaucoup d'autres types d'interaction avec les ressources. C'est un problème car cela a conduit de nombreuses personnes à supposer que HTTP est juste pour GETing. Mais HTTP est en fait un protocole général pour appliquer des verbes aux noms.

Épouse: Cool. Mais je ne vois toujours pas comment cela change quoi que ce soit. Quels types de noms et de verbes voulez-vous?

Ryan: Et bien les noms sont là mais pas dans le bon format.

Pensez à lorsque vous naviguez sur amazon.com à la recherche de choses à m'acheter pour Noël. Imaginez chacun des produits comme des noms. Maintenant, s'ils étaient disponibles dans une représentation qu'une machine pouvait comprendre, vous pourriez faire beaucoup de choses intéressantes.

Épouse: Pourquoi une machine ne peut-elle pas comprendre une page Web normale?

Ryan: Parce que les pages Web sont conçues pour être comprises par les gens. Une machine ne se soucie pas de la mise en page et du style. Les machines ont simplement besoin des données. Idéalement, chaque URL aurait une représentation lisible par l'homme et lisible par une machine. Lorsqu'une machine obtient la ressource, elle demandera celle lisible par la machine. Lorsqu'un navigateur OBTIENT une ressource pour un humain, il demandera celle qui est lisible par l'homme.

Épouse: Donc, les gens devraient faire des formats de machine pour toutes leurs pages?

Ryan: Si cela avait de la valeur.

Écoutez, nous en avons parlé avec beaucoup d'abstraction. Et si nous prenions un vrai exemple. Vous êtes enseignant - à l'école, je parie que vous avez un gros système informatique, ou trois ou quatre systèmes informatiques plus susceptibles, qui vous permettent de gérer les élèves: quelles classes ils sont, quelles notes ils obtiennent, contacts d'urgence, informations sur les livres que vous enseignez, etc. Si les systèmes sont basés sur le Web, il y a probablement une URL pour chacun des noms impliqués ici: étudiant, enseignant, classe, livre, salle, etc. En ce moment, obtenir l'URL le navigateur vous donne une page Web. S'il y avait une représentation lisible par machine pour chaque URL, alors il serait trivial de verrouiller de nouveaux outils sur le système car toutes ces informations seraient consommables de manière standard. Cela faciliterait également la conversation de chacun des systèmes. Ou, vous pouvez créer un système national ou national capable de parler à chacun des systèmes scolaires individuels pour collecter les résultats des tests. Les possibilités sont infinies.

Chacun des systèmes obtiendrait des informations les uns des autres à l'aide d'un simple HTTP GET. Si un système doit ajouter quelque chose à un autre système, il utilise un HTTP POST. Si un système veut mettre à jour quelque chose dans un autre système, il utilise un HTTP PUT. La seule chose qui reste à comprendre est à quoi devraient ressembler les données.

Épouse: C'est donc sur cela que vous et tous les informaticiens travaillez maintenant? Décider à quoi devraient ressembler les données?

Ryan: Malheureusement non. Au lieu de cela, la grande majorité est occupée à écrire des couches de spécifications complexes pour faire ce genre de choses d'une manière différente qui n'est pas aussi utile ou éloquente. Les noms ne sont pas universels et les verbes ne sont pas polymorphes. Nous jetons des décennies d'utilisation réelle sur le terrain et de technique éprouvée et recommençons avec quelque chose qui ressemble beaucoup à d'autres systèmes qui ont échoué dans le passé. Nous utilisons HTTP, mais uniquement parce qu'il nous aide à parler moins à notre réseau et aux personnes chargées de la sécurité. Nous échangeons la simplicité contre des outils et des assistants flashy.

Épouse: Pourquoi?

Ryan: Je n'en ai aucune idée.

Épouse: Pourquoi tu ne dis pas quelque chose?

Ryan: Peut - être que je le ferai.

Comment pensez-vous qu'il serait possible de stocker l'état de milliards de milliards de milliards de milliards de connexions? :) Ainsi, vous ne stockez l'état que si nécessaire, dans les sessions.

BTW: HTTP n'est pas sans connexion.

En tant que développeur de bureau, vous pouvez être plus à l'aise avec des expériences d'interface utilisateur riches. Passer au Web, c'est comme prendre du recul. Dans le monde du Web, il y a moins de liberté de créativité et cela peut vous donner un sentiment de contrainte. Ne vous laissez pas abattre! Il existe un certain nombre de choses qui peuvent vous aider à faire la transition et en voici une courte liste:

1. L'état peut être partagé mais est fréquemment conservé sur le serveur et référencé à l'aide de jetons tels que les identifiants de session, les paramètres d'URL, les champs masqués ou les valeurs des cookies.
2. Les modèles sans état sont bien adaptés au traitement des transactions. Essayez de construire votre modèle de manière à réduire la quantité d'état requise. Les principes ACID du traitement des transactions peuvent vous y aider.
3. Familiarisez-vous avec le modèle MVC (si vous ne l'êtes pas déjà). Cela vous aidera à améliorer votre conception en maintenant une séparation des préoccupations. Certains frameworks populaires tels que Struts (Java) et MVC (.NET) sont construits autour de ce concept.
4. Envisagez d'utiliser un plugin tel que Java , Flash ou Silverlight pour des expériences d'interface utilisateur super riches. Pour les expériences semi-riches, envisagez d'utiliser des bibliothèques basées sur des scripts Java populaires telles que JQuery ou AJAX .

Bonne programmation!

Parce qu'il fut un temps où il n'y avait pas des millions et des millions de pages Web. Parce qu'il fut un temps où seules les universités et les centres de recherche disposaient de quelques pages. Il fut un temps où il n'y avait pas de large bande, et http était communiqué avec 1200 modems en bauds placés sur des téléphones de bureau. Il fut un temps où des «applications Web riches» auraient nécessité, selon elles, une bande passante ridicule. Et rappelez-vous, TCP / IP a été créé parce que le début d'Internet n'était pas très fiable.

HTTP 1.0 existait au début des années 1990. Réfléchissez à la façon dont Internet d'alors était, et pourquoi ils l'ont conçu comme ils l'ont fait.

Tout cela a évolué. Internet existait avant les navigateurs Web et le Web. C'était un pot bouillonnant de ftp, telnet, gopher, ping, finger et quelques autres bits et bobs. Le premier navigateur Web, Mosaic (? Je pense, c'était il y a longtemps, 1991 je pense, j'étais au collège) a agi comme une sorte de méli-mélo entre ftp et un visualiseur de documents. La magie s'est produite en ce que vous pouviez avoir des liens dans le document qui pourraient créer un nouveau document.

Toute l'interactivité que nous avons maintenant évoluée au cours des 20 années suivantes. Ce n'était pas non plus une évolution heureuse. Nous avons eu les guerres des navigateurs, IE et Netscape l'ont éliminé pour le contrôle des normes (un peu de simplification;)), et divers autres tiers ont commencé à introduire des plug-ins pour permettre un contenu riche. Java allait être la balle magique et bien sûr Flash. Est-ce que quelqu'un se souvient des plug-ins VRML qui promettaient des mondes 3D et livraient exactement une demi-douzaine de modèles 3D de modèles Star Wars?

Je me suis un peu emporté vers la fin, mais vous voyez l'idée :)

Les principales raisons ont à voir avec une combinaison de ce que l'acédémie croyait que le but du HTTP était, et pour des raisons d'évolutivité. HTML a été initialement conçu pour partager des informations ou des thèses au-delà des frontières académiques. C'était un texte purement stylisé. Ce n'est que lorsque le premier navigateur vous a permis de diffuser des images que les gens ont commencé à penser au-delà de ce modèle.

Les considérations suivantes ont solidifié la décision d'apatridie:

• L'interaction typique allait être un téléchargement rapide et une lecture. Pendant le délai jusqu'à la prochaine demande, la prise serait inactive.
• Les sockets occupent de précieuses ressources système. Si nous n'avions pas à maintenir une conversation comme vous le feriez avec SMTP, vous pouvez faire beaucoup pour qu'une seule machine gère des milliers de clients.
• Ils ont déjà tiré de précieuses leçons de la gestion de comptes shell distants, NFS, SMTP et d'autres protocoles de connexion avec état.

À mesure que les pages Web devenaient plus complexes et comprenaient de nombreux graphiques et feuilles de style, HTTP a été modifié avec le drapeau "keep-alive". Cela garderait le socket actif et permettrait au client de demander plusieurs ressources avec la même conversation.

Compte tenu du modèle d'utilisation actuel d'Internet, la décision initiale est toujours valable. Cela peut parfois être gênant, mais plusieurs petites interactions quantifiées avec un serveur évoluent mieux que les sockets inactives.

Si vous parlez de navigateurs bidirectionnels.

Raisons de sécurité.

Par exemple SPAM !.

Faire passer la communication bidirectionnelle sur le Web au niveau supérieur

Sinon, Internet exécute TCP / IP (deux protocoles) et UDP.

Le protocole de contrôle de transmission(TCP) est l'un des principaux protocoles d'Internet Protocol Suite. TCP est l'un des deux composants originaux de la suite, complétant le protocole Internet (IP), et par conséquent la suite entière est communément appelée TCP / IP. TCP fournit le service d'échange de données directement entre deux hôtes sur le même réseau, tandis qu'IP gère l'adressage et le routage des messages sur un ou plusieurs réseaux. En particulier, TCP fournit une distribution ordonnée et fiable d'un flux d'octets d'un programme sur un ordinateur à un autre programme sur un autre ordinateur. TCP est le protocole sur lequel s'appuient les principales applications Internet, telles que le World Wide Web, le courrier électronique et le transfert de fichiers. D'autres applications, qui ne nécessitent pas de service de flux de données fiable,

Le protocole Internet(IP) est le principal protocole de communication utilisé pour relayer des datagrammes (paquets) à travers un interréseau à l'aide d'Internet Protocol Suite. Responsable du routage des paquets à travers les frontières du réseau, c'est le protocole principal qui établit Internet. IP est le protocole principal de la couche Internet de la suite de protocoles Internet et a pour tâche de fournir des datagrammes de l'hôte source à l'hôte de destination uniquement en fonction de leurs adresses. À cette fin, IP définit les méthodes et structures d'adressage pour l'encapsulation des datagrammes. Historiquement, IP était le service de datagramme sans connexion dans le programme de contrôle de transmission original introduit par Vint Cerf et Bob Kahn en 1974, l'autre étant le protocole de contrôle de transmission orienté connexion (TCP). La suite de protocoles Internet est donc souvent appelée TCP / IP.

Dans une application de bureau, l'utilisateur est supposé effectuer une série de tâches, avec un début et une fin définis. Dans une telle application, il est logique (pas beaucoup, en fait) que les utilisateurs se connectent au serveur qui fournit leurs données et restent connectés jusqu'à ce qu'ils aient terminé.

Les interactions Web ne suivent pas (généralement) le même modèle. Dans un site de commerce électronique, par exemple, un utilisateur peut arriver à une description de produit à la suite d'une recherche Google et quitter immédiatement cette page pour regarder l'offre d'un autre site du même produit. Ou il / elle peut commencer le processus de paiement, puis décider que le produit est trop cher et l'abandonner à mi-parcours. L'idée de base de «l'hypertexte» implique la capacité et l'attente de sauter d'un endroit à un autre.

Les connexions permanentes consomment des ressources. Peut-être juste un socket réseau, peut-être un pool de requêtes de base de données analysées; tout dépend de l'application. Étant donné qu'un utilisateur peut disparaître à tout moment, il n'est pas très logique de maintenir ces ressources engagées.

En pratique, l'utilisateur n'a pas vraiment besoin d'avoir une connexion permanente. L'application Web maintient des connexions à toutes les ressources (par exemple, la base de données) dont elle a besoin et les partage entre toutes les demandes des utilisateurs. Le cadre d'application Web fournit des sessions, qui sont des lieux limités dans le temps pour stocker des données par utilisateur pour différentes demandes. La seule chose que vous ne pouvez pas faire (facilement) est d'avoir des transactions contrôlées par le client de longue durée, mais c'est une mauvaise idée même dans une application qui maintient des connexions.

Internet n'est pas nécessairement apatride - en fait, lorsque vous regardez Java EE - ils ont des EJB avec état et des EJB sans état.

La raison principale pour laquelle les développeurs recommandent d'utiliser une architecture sans état est en raison de l'évolutivité. Imaginez-vous essayer de garder l'état de tous vos utilisateurs une fois que vous ajoutez et supprimez des serveurs pour prendre en charge votre trafic.

Ce n'est vraiment pas difficile de développer une architecture sans état. L'essentiel est de conserver le moins possible d'état (généralement un identifiant utilisateur - de préférence dans un cookie) et de modifier la base de données selon les besoins.

Je pense que cela a commencé de cette façon et a continué de l'être. Maintenant qu'il y a tellement d'infrastructures construites autour d'elle, il est impossible de la changer.

Peut-être qu'il a commencé sans état, car les connexions étaient moins fiables au début, et la bande passante était également plus petite. Si vous n'avez pas beaucoup de connexions actives, vous pouvez gérer plus de trafic plus facilement.

Veuillez modifier ou laisser un commentaire si vous avez de meilleures informations, ou mieux encore, postez votre propre réponse!

C'est parce que les serveurs fournissent un service (c'est dans le nom). Vous faites une demande et recevez des réponses - c'est tout ce qu'il y a à faire.

En ce qui concerne la transition vers le développement Web, je crois que les formulaires Web ASP.NET le feront d'une manière qui vous sera plus compréhensible - mais ce n'est que parce qu'il cache ce qui se passe réellement sous des couches d'abstraction.

Beaucoup peut être compris en analysant le nom de HTTP (HyperText Transfer Protocol). Il n'a jamais été conçu pour être un protocole d'interface utilisateur riche. L'idée originale était de partager des documents avec des liens entre eux. Je vous demande un document, vous répondez avec une copie de ce document.

À l'origine, HTTP n'avait qu'un seul verbe GET. À cet égard, il a été conçu pour le contenu statique. Pourquoi avez-vous besoin d'indiquer quand tout ce que vous faites est de demander un document que quelqu'un partage? Et c'est pourquoi HTTP est apatride ... en raison de ses origines.