Share
Dans le premier chapitre, nous avons parlé de ressources, mais principalement d’URL et de l’interprétation d’une URL. Cependant, les ressources sont la pièce maîtresse de HTTP. Maintenant que nous comprenons les messages HTTP, les méthodes et les connexions, nous pouvons revenir à examiner les ressources sous un nouveau jour. Dans ce chapitre, nous allons parler de la véritable essence du travail avec des ressources lors de l’architecture d’applications Web et de services Web..
Bien qu'il soit facile de penser à une ressource Web en tant que fichier sur le système de fichiers d'un serveur Web, une telle démarche ne respecte pas la véritable capacité de l'abstraction de la ressource. De nombreuses pages Web nécessitent des ressources physiques sur un système de fichiers: fichiers JavaScript, images et feuilles de style. Cependant, les consommateurs et les utilisateurs du Web se soucient peu de ces ressources en arrière-plan. Au lieu de cela, ils se soucient des ressources avec lesquelles ils peuvent interagir et, plus important encore, des ressources qu'ils peuvent nommer. Des ressources comme:
Toutes ces ressources sont les types de ressources sur lesquelles nous construisons des applications, et le thème commun de la liste est la façon dont chaque élément est suffisamment significatif pour être identifié et nommé. Si nous pouvons identifier une ressource, nous pouvons également lui attribuer une URL permettant à quelqu'un de la localiser. Une URL est une chose pratique à avoir autour. Bien sûr, avec une URL, vous pouvez localiser une ressource, mais vous pouvez également transmettre l’URL à une autre personne en incorporant l’URL dans un lien hypertexte ou en l’envoyant dans un courrier électronique..
Mais il y a beaucoup de choses que vous ne pouvez pas faire avec une URL. Plutôt, il y a beaucoup de choses qu'une URL ne peut pas faire. Par exemple, une URL ne peut pas restreindre le client ou le serveur à un type de technologie spécifique. Tout le monde parle HTTP. Peu importe que votre client soit en C ++ et que votre application Web soit en Ruby..
De plus, une URL ne peut pas forcer le serveur à stocker une ressource en utilisant une technologie particulière. La ressource peut être un document sur le système de fichiers, mais un framework Web peut également répondre à la demande de la ressource et construire la ressource en utilisant les informations stockées dans des fichiers, stockées dans des bases de données, extraites de services Web, ou extraire la ressource du fichier actuel. moment de la journée.
Une URL ne peut même pas spécifier la représentation d'une ressource spécifique et une ressource peut avoir plusieurs représentations. Comme nous l'avons appris précédemment, un client peut demander une représentation particulière en utilisant des en-têtes dans le message de requête HTTP. Un client peut demander une langue spécifique ou un type de contenu spécifique. Si vous avez déjà travaillé avec une application Web permettant la négociation de contenu, vous avez constaté la flexibilité des ressources en action. JavaScript peut demander les données du patient 123 au format JSON, C # peut demander la même ressource au format XML et un navigateur peut demander les données au format HTML. Ils travaillent tous avec la même ressource, mais en utilisant trois représentations différentes.
Une URL ne peut pas faire plus: elle ne peut pas dire ce qu'un utilisateur veut faire avec une ressource. Une URL ne dit pas si je veux récupérer une ressource ou en modifier une. C'est le travail du message de requête HTTP de décrire cette intention en utilisant l'une des méthodes standard HTTP. Comme nous en avons parlé dans la partie 2 de cette session, il existe un nombre limité de méthodes HTTP standard, y compris OBTENIR, POSTER, METTRE, et EFFACER.
Lorsque vous commencez à penser aux ressources et aux URL comme nous le voyons dans ce chapitre, vous commencez à voir le Web comme une partie de votre application et une couche architecturale flexible sur laquelle vous pouvez vous appuyer. Pour en savoir plus sur cette ligne de pensée, consultez la célèbre thèse de Roy Fielding intitulée "Styles architecturaux et conception d'architectures logicielles basées sur un réseau". Cette thèse est le document qui introduit le style d'architecture représentationnel (REST) et décrit plus en détail les idées et les concepts présentés dans cette section et dans la suivante. L'article se trouve sur http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
Jusqu'à présent, nous nous sommes concentrés sur ce qu'une URL ne peut pas faire, quand nous devrions nous concentrer sur ce qu'une URL peut faire. Ou plutôt, concentrez-vous sur ce qu'une URL et un HTTP peuvent faire, car ils fonctionnent parfaitement ensemble. Dans sa thèse, Fielding décrit les avantages de l'adoption de HTTP. Ces avantages comprennent l'évolutivité, la simplicité, la fiabilité et un couplage lâche. HTTP offre ces avantages en partie car vous pouvez considérer une URL comme un pointeur ou une unité d'indirection entre une application cliente et une application serveur. Encore une fois, l'URL elle-même ne dicte pas une représentation de ressource spécifique, une implémentation technologique ou l'intention du client. Au lieu de cela, un client peut exprimer l’intention et la représentation souhaitées dans un message HTTP..
Un message HTTP est un message simple et textuel. La beauté du message HTTP réside dans le fait que la demande et la réponse se décrivent elles-mêmes. Une demande inclut la méthode HTTP (ce que le client veut faire), le chemin d'accès à la ressource et des en-têtes supplémentaires fournissant des informations sur la représentation souhaitée. Une réponse comprend un code d'état pour indiquer le résultat de la transaction, mais comprend également des en-têtes avec des instructions de cache, le type de contenu de la ressource, la longueur de la ressource et éventuellement d'autres métadonnées utiles..
Parce que toutes les informations requises pour une transaction sont contenues dans les messages et que les informations sont visibles et faciles à analyser, les applications HTTP peuvent compter sur un certain nombre de services offrant une valeur ajoutée lors du transfert d'un message entre l'application cliente et l'application serveur..
Lorsqu'un message HTTP se déplace de la mémoire d'un processus d'une machine à la mémoire d'un processus d'une autre machine, il peut se déplacer dans plusieurs logiciels et matériels qui inspectent et modifient éventuellement le message. Un bon exemple est l'application de serveur Web elle-même. Un serveur Web comme Apache ou IIS sera l'un des premiers destinataires d'une requête HTTP entrante sur un serveur. En tant que serveur Web, il peut acheminer le message vers l'application appropriée..
Le serveur Web peut utiliser les informations contenues dans un message, telles que l'URL ou l'en-tête de l'hôte, pour décider où envoyer un message. Le serveur peut également effectuer des actions supplémentaires avec le message, comme consigner le message dans un fichier local. Les applications sur le serveur n'ont pas besoin de s'inquiéter de la journalisation car le serveur est configuré pour journaliser tous les messages..
De même, lorsqu'une application crée un message de réponse HTTP, le serveur a la possibilité d'interagir avec le message à la sortie. Encore une fois, cela pourrait être une simple opération de journalisation, mais cela pourrait aussi être une modification directe du message lui-même. Par exemple, un serveur peut savoir si un client prend en charge la compression gzip, puisqu'un client peut annoncer ce fait par le biais d'un Accepter l'encodage en-tête dans la requête HTTP. La compression permet à un serveur de prendre une ressource de 100 Ko et de la transformer en une ressource de 25 Ko pour une transmission plus rapide. Vous pouvez configurer de nombreux serveurs Web pour qu'ils utilisent automatiquement la compression pour certains types de contenu (généralement des types de texte), sans que l'application elle-même se préoccupe de la compression. La compression est une valeur ajoutée fournie par le logiciel du serveur Web lui-même..
Les applications n'ont pas à s'inquiéter de la journalisation des transactions HTTP ou de la compression, et tout cela grâce aux messages HTTP auto-descriptifs qui permettent à d'autres éléments d'infrastructure de traiter et de transformer des messages. Ce type de traitement peut également se produire lorsque le message est transmis sur le réseau..
UNE Serveur proxy est un ordinateur situé entre un client et un serveur. Un proxy est principalement transparent pour les utilisateurs finaux. Vous pensez que vous envoyez des messages de requête HTTP directement à un serveur, mais les messages sont envoyés à un proxy. Le proxy accepte les messages de requête HTTP provenant d'un client et les transmet au serveur souhaité. Le proxy prend ensuite la réponse du serveur et la renvoie au client. Avant de transférer ces messages, le proxy peut inspecter les messages et éventuellement prendre des mesures supplémentaires..
L'un des clients pour lequel je travaille utilise un serveur proxy pour capturer tout le trafic HTTP quittant le bureau. Ils ne veulent pas que les employés et les sous-traitants passent tout leur temps sur Twitter et Facebook. Par conséquent, les demandes HTTP adressées à ces serveurs n'atteindront jamais leur destination et il n'y a pas de tweet ou de Farmville dans le bureau. Ceci est un exemple d'un rôle populaire pour les serveurs proxy, qui doit fonctionner comme un périphérique de contrôle d'accès.
Toutefois, un serveur proxy peut être beaucoup plus sophistiqué que de simplement envoyer des messages à des hôtes spécifiques: un simple pare-feu peut s’acquitter de cette tâche. Un serveur proxy pourrait également inspecter les messages pour supprimer les données confidentielles, comme le Référant en-têtes qui pointent vers des ressources internes sur le réseau de l'entreprise. Un proxy de contrôle d'accès peut également consigner des messages HTTP pour créer des journaux d'audit sur tout le trafic. De nombreux serveurs proxy de contrôle d'accès nécessitent une authentification de l'utilisateur, un sujet que nous verrons dans le prochain article..
Le proxy que je décris dans le paragraphe précédent est ce que nous appelons un proxy direct. Les mandataires de transfert sont généralement plus proches du client que du serveur et les mandataires de transfert nécessitent généralement une certaine configuration dans le logiciel client ou le navigateur Web pour fonctionner..
UNE proxy inverse est un serveur proxy plus proche du serveur que du client et totalement transparent pour le client.
Proxy direct et inverse Les deux types de mandataires peuvent fournir une large gamme de services. Si nous revenons au scénario de compression gzip dont nous avons parlé plus tôt, un serveur proxy a la capacité de compresser les corps des messages de réponse. Une entreprise peut utiliser un serveur proxy inverse pour la compression afin de réduire la charge de calcul des serveurs Web sur lesquels l’application réside. Désormais, ni l'application ni le serveur Web ne doivent s'inquiéter de la compression. Au lieu de cela, la compression est une fonctionnalité qui est stratifiée via un proxy. C'est la beauté de HTTP.
Certains autres services proxy populaires incluent les suivants:.
L'équilibrage de charge Les mandataires peuvent prendre un message et le transférer à l'un des serveurs Web tour à tour, ou en sachant quel serveur traite actuellement le moins de demandes..
Accélération SSL Les mandataires peuvent chiffrer et déchiffrer les messages HTTP, ce qui évite le chiffrement d'un serveur Web. Nous parlerons plus de SSL dans le prochain chapitre.
Les mandataires peuvent fournir une couche supplémentaire de Sécurité en filtrant les messages HTTP potentiellement dangereux. Plus précisément, les messages qui donnent l'impression de tenter de détecter une vulnérabilité de script intersite (XSS) ou de lancer une attaque par injection SQL.
Mise en cache des mandataires peut stocker des copies des ressources fréquemment consultées et répondre aux messages demandant directement ces ressources. Nous détaillerons la mise en cache dans la section suivante..
Enfin, il convient de souligner qu’un proxy ne doit pas nécessairement être un serveur physique. Fiddler, un outil mentionné dans le chapitre précédent, est un débogueur HTTP qui vous permet de capturer et d’inspecter les messages HTTP. Fiddler indique à Windows de transférer tout le trafic HTTP sortant vers le port 8888 de l’adresse IP 127.0.0.1. Cette adresse IP est l'adresse de bouclage, ce qui signifie que le trafic va simplement directement à la machine locale où Fiddler est à l'écoute sur le port 8888. Fiddler prend le message de requête HTTP, le consigne, le transfère à la destination et capture également la réponse avant le transfert. la réponse à l'application locale. Vous pouvez afficher les paramètres de proxy dans Internet Explorer (IE) en allant à Outils, options Internet, en cliquant sur le Les liaisons onglet, puis en cliquant sur le Paramètres lan bouton. Sous le Serveur proxy zone, cliquez sur le Avancée bouton pour voir les détails du serveur proxy.
Paramètres de proxy dans Internet Explorer Les mandataires illustrent parfaitement l’influence de HTTP sur l’architecture d’une application Web ou d’un site Web. Il existe de nombreux services que vous pouvez superposer au réseau sans impacter l'application. Le service que nous voulons examiner plus en détail est la mise en cache..
La mise en cache est une optimisation visant à améliorer les performances et l'évolutivité. Lorsqu'il y a plusieurs demandes pour la même représentation de ressources, un serveur peut envoyer les mêmes octets sur le réseau à maintes reprises pour chaque demande. Ou bien, un serveur proxy ou un client peut mettre en cache la représentation localement et réduire le temps et la bande passante requis pour une récupération complète. La mise en cache peut réduire la latence, aider à prévenir les goulots d'étranglement et permettre à une application Web de survivre lorsque chaque utilisateur se présente en même temps pour acheter le dernier produit ou consulter le dernier communiqué de presse. La mise en cache est également un excellent exemple de la manière dont les métadonnées dans les en-têtes de message HTTP facilitent la création de couches et de services supplémentaires..
La première chose à savoir est qu’il existe deux types de caches.
UNE cache public est un cache partagé entre plusieurs utilisateurs. Un cache public réside généralement sur un serveur proxy. Un cache public sur un proxy direct met généralement en cache les ressources populaires dans une communauté d'utilisateurs, tels que les utilisateurs d'une société spécifique ou les utilisateurs d'un fournisseur de services Internet spécifique. Un cache public sur un proxy inverse met généralement en cache les ressources populaires sur un site Web spécifique, telles que les images de produits populaires d'Amazon.com..
UNE cache privé est dédié à un utilisateur unique. Les navigateurs Web conservent toujours un cache privé de ressources sur votre disque (il s’agit des "fichiers Internet temporaires" dans IE, ou tapez à propos de: cache dans la barre d’adresse de Google Chrome pour voir les fichiers dans le cache privé de Chrome). Tout ce qu'un navigateur a mis en cache sur le système de fichiers peut apparaître presque instantanément à l'écran.
Les règles sur ce qu'il faut mettre en cache, quand mettre en cache et quand invalider un élément de cache (c'est-à-dire le retirer du cache), sont malheureusement compliquées et masquées par certains comportements hérités et par des implémentations incompatibles. Néanmoins, je vais essayer de souligner certaines des choses que vous devez savoir sur la mise en cache.
Dans HTTP 1.1, un message de réponse avec un code d’état 200 (OK) pour un HTTP OBTENIR La requête est mise en cache par défaut (ce qui signifie qu'il est légal pour les mandataires et les clients de mettre en cache la réponse). Une application peut influencer ce paramètre par défaut en utilisant les en-têtes appropriés dans une réponse HTTP. Dans HTTP 1.1, cet en-tête est le Cache-Control en-tête, bien que vous puissiez aussi voir un Expire en-tête dans de nombreux messages aussi. le Expire l'en-tête est toujours présent et est largement pris en charge bien qu'il soit déconseillé dans HTTP 1.1. Pragma est un autre exemple d’en-tête utilisé pour contrôler le comportement de la mise en cache, mais il n’est vraiment là que pour la compatibilité descendante. Dans ce livre, je vais me concentrer sur Cache-Control.
Une réponse HTTP peut avoir une valeur pour Cache-Control de Publique, privé, ou no-cache. Une valeur de Publique signifie que les serveurs proxy publics peuvent mettre en cache la réponse. Une valeur de privé signifie que seul le navigateur peut mettre en cache la réponse. Une valeur de no-cache signifie que personne ne devrait mettre en cache la réponse. Il y a aussi pas de magasin valeur, ce qui signifie que le message peut contenir des informations sensibles et ne doit pas être conservé, mais doit être supprimé de la mémoire dès que possible.
Comment utilisez-vous cette information? Pour les ressources partagées populaires (comme l’image du logo de la page d’accueil), vous pouvez utiliser un Publique directive de contrôle de cache et autoriser tout le monde à mettre en cache l'image, même les serveurs proxy.
Pour les réponses à un utilisateur spécifique (comme le code HTML de la page d'accueil contenant le nom de l'utilisateur), vous souhaitez utiliser une directive de cache privé..
Remarque: En ASP.NET, vous pouvez contrôler ces paramètres via Response.Cache.
Un serveur peut aussi spécifier un max-age valeur dans le Cache-Control. le max-age valeur est le nombre de secondes pour mettre en cache la réponse. Une fois ces secondes écoulées, la demande doit toujours retourner sur le serveur pour récupérer une réponse mise à jour. Regardons quelques exemples de réponses.
Voici une réponse partielle de Flickr.com pour l'un des fichiers CSS de Flickr.
HTTP / 1.1 200 OK Dernière mise à jour: mer., 25 janv. 2012 17:55:15 GMT Expire le: samedi 22 janvier 2022 17:55:15 GMT Cache-Control: max-age = 315360000, public
Remarquez le Cache-Control permet aux caches publics et privés de mettre en cache le fichier et de le conserver pendant plus de 315 millions de secondes (10 ans). Ils utilisent aussi un Expire en-tête pour donner une date d'expiration spécifique. Si un client est conforme à HTTP 1.1 et comprend Cache-Control, il faut utiliser la valeur dans max-age au lieu de Expire. Notez que cela ne signifie pas que Flickr envisage d'utiliser le même fichier CSS pendant 10 ans. Lorsque Flickr changera de conception, il utilisera probablement une URL différente pour son fichier CSS mis à jour..
La réponse comprend également un Dernière modification header pour indiquer quand la représentation a été modifiée pour la dernière fois (ce qui pourrait être simplement l'heure de la requête). La logique du cache peut utiliser cette valeur en tant que validateur, ou une valeur que le client peut utiliser pour voir si la représentation en cache est toujours valide. Par exemple, si l'agent décide qu'il a besoin de vérifier la ressource, il peut émettre la demande suivante..
GET… HTTP / 1.1 If-Modified-Since: mer., 25 janv. 2012 17:55:15 GMT
le Si-Modifié-Depuis header indique au serveur que le client n'a besoin de la réponse complète que si la ressource a changé. Si la ressource n'a pas changé, le serveur peut répondre par un message. 304 non modifié message.
HTTP / 1.1 304 non modifié Expire le: sam. 22 janv. 2022 17:16:19 GMT Cache-Control: max-age = 315360000, public
Le serveur dit au client: Allez-y et utilisez les octets que vous avez déjà mis en cache..
Un autre validateur que vous verrez couramment est le ETag.
HTTP / 1.1 200 OK Serveur: Apache Dernière mise à jour: vendredi, 06 janv. 2012 18:08:20 GMT Heure: "8e5bcd-59f-4b5dfef104d00" Content-Type: text / xml Variable: Accept-Encoding Content-Codage: gzip Content -Longueur: 437
le ETag est un identifiant opaque, ce qui signifie qu'il n'a pas de signification inhérente. Un ETag est souvent créé en utilisant un algorithme de hachage sur la ressource. Si la ressource change, le serveur calculera une nouvelle ETag. Une entrée de cache peut être validée en comparant deux ETags. Si la ETags sont les mêmes, rien n'a changé. Si la ETags sont différents, il est temps d'invalider le cache.
Dans ce chapitre, nous avons traité de la théorie architecturale ainsi que des avantages pratiques de l’architecture HTTP. La possibilité de superposer la mise en cache et d’autres services entre un serveur et un client a été une force motrice du succès de HTTP et du Web. La visibilité des messages HTTP auto-descriptifs et de l'indirection fournie par les URL rend tout cela possible. Dans le chapitre suivant, nous aborderons quelques-uns des sujets que nous avons abordés, tels que l’authentification et le cryptage..
Accentsconagua