031.2 Leçon 1
Certification : |
Web Development Essentials |
---|---|
Version : |
1.0 |
Thème : |
031 Développement de logiciels et technologies Web |
Objectif : |
031.2 Architecture des applications Web |
Leçon : |
1 sur 1 |
Introduction
Le mot application a un sens large dans le jargon technologique. Lorsque l’application est un programme traditionnel, exécuté localement et autosuffisant dans sa finalité, l’interface d’exploitation de l’application et les composants de traitement des données sont intégrés dans un seul “paquet”. Une application web est différente car elle adopte le modèle client/serveur et sa partie client est basée sur le langage HTML, qui est obtenu du serveur et, en général, rendu par un navigateur.
Clients et serveurs
Dans le modèle client/serveur, une partie du travail est effectuée localement, du côté du client, et une partie du travail est effectuée à distance, du côté du serveur. Les tâches effectuées par chaque partie varient en fonction de l’objectif de l’application, mais en général, c’est au client de fournir une interface à l’utilisateur et de présenter le contenu de manière attrayante. C’est au serveur qu’il revient d’exécuter l’aspect business de l’application, en traitant et en répondant aux requêtes faites par le client. Dans une application d’achat, par exemple, l’application client affiche une interface permettant à l’utilisateur de choisir et de payer les produits, mais la source de données et les enregistrements de la transaction sont conservés sur le serveur distant, auquel on accède via le réseau. Les applications web effectuent cette communication sur Internet, généralement via le protocole de transfert hypertexte (HTTP).
Une fois chargé par le navigateur, le côté client de l’application initie une interaction avec le serveur chaque fois que cela est nécessaire ou pratique. Les serveurs d’applications web offrent une interface de programmation d’applications (API : Application Programming Interface) qui définit les requêtes disponibles et la manière dont ces requêtes doivent être effectuées. Ainsi, le client construit une requête dans le format défini par l’API et l’envoie au serveur, qui vérifie les conditions préalables à la requête et renvoie la réponse appropriée.
Alors que le client, sous la forme d’une application mobile ou d’un navigateur de bureau, est un programme autonome en ce qui concerne l’interface utilisateur et les instructions de communication avec le serveur, le navigateur doit obtenir la page HTML et les composants associés (images, CSS et JavaScript) qui définissent l’interface et les instructions de communication avec le serveur.
Les langages de programmation et les plates-formes utilisés par le client et le serveur sont indépendants, mais utilisent un protocole de communication mutuellement compréhensible. La partie serveur est presque toujours exécutée par un programme sans interface graphique, qui fonctionne dans des environnements informatiques hautement disponibles afin d’être toujours prêt à répondre aux requêtes. En revanche, la partie client s’exécute sur tout appareil capable de restituer une interface HTML, comme les smartphones.
En plus d’être indispensable à certains usages, l’adoption du modèle client/serveur permet à une application d’optimiser plusieurs aspects du développement et de la maintenance, puisque chaque partie peut être conçue pour son usage spécifique. Une application qui affiche des cartes et des itinéraires, par exemple, n’a pas besoin d’avoir toutes les cartes stockées localement. Seules les cartes relatives à l’endroit qui intéresse l’utilisateur sont nécessaires, et seules ces cartes sont demandées au serveur central.
Les développeurs ont un contrôle direct sur le serveur, ils peuvent donc également modifier le client qui est fourni par celui-ci. Cela permet aux développeurs d’améliorer l’application, dans une plus ou moins grande mesure, sans que l’utilisateur ait besoin d’installer explicitement de nouvelles versions.
Côté client
Une application web devrait fonctionner de la même manière sur n’importe quel navigateur parmi les plus populaires, pour autant que le navigateur soit à jour. Certains navigateurs peuvent être incompatibles avec des innovations récentes, mais seules les applications expérimentales utilisent des fonctionnalités qui ne sont pas encore largement adoptées.
Les problèmes d’incompatibilité étaient plus fréquents dans le passé, lorsque les différents navigateurs possédaient leur propre moteur de rendu et qu’il y avait moins de coopération dans la formulation et l’adoption de normes. Le moteur de rendu est le principal composant du navigateur, car il est chargé de transformer le HTML et les autres composants associés en éléments visuels et interactifs de l’interface. Certains navigateurs, notamment Internet Explorer, nécessitaient un traitement spécial dans le code afin de ne pas casser le fonctionnement attendu des pages.
Aujourd’hui, les différences entre les principaux navigateurs sont minimes, et les incompatibilités sont rares. En fait, les navigateurs Chrome et Edge utilisent le même moteur de rendu (appelé Blink). Le navigateur Safari, et d’autres navigateurs proposés sur l’App Store d’iOS, utilisent le moteur WebKit. Firefox utilise un moteur appelé Gecko. Ces trois moteurs représentent la quasi-totalité des navigateurs utilisés aujourd’hui. Bien que développés séparément, ces trois moteurs sont des projets open source et il existe une coopération entre leurs développeurs, ce qui facilite la compatibilité, la maintenance et l’adoption de normes.
Comme les développeurs de navigateurs ont fait beaucoup d’efforts pour rester compatibles, le serveur n’est normalement pas lié à un seul type de client. En principe, un serveur HTTP peut communiquer avec n’importe quel client qui est également capable de communiquer via HTTP. Dans une application cartographique, par exemple, le client peut être une application mobile ou un navigateur qui charge l’interface HTML depuis le serveur.
Variétés de clients Web
Il existe des applications mobiles et de bureau dont l’interface est rendue à partir du HTML et qui, comme les navigateurs, peuvent utiliser JavaScript comme langage de programmation. Cependant, contrairement au client chargé dans le navigateur, le HTML et les composants nécessaires au fonctionnement du client natif sont présents localement depuis l’installation de l’application. En fait, une application qui fonctionne de cette manière est pratiquement identique à une page HTML (les deux sont même susceptibles d’être rendues par le même moteur). Il existe également des applications web progressives (PWA : Progressive Web Apps), un mécanisme qui permet de packager des clients d’applications web pour une utilisation hors connexion, limitée aux fonctions qui ne nécessitent pas de communication immédiate avec le serveur. En ce qui concerne ce que l’application peut faire, il n’y a pas de différence entre l’exécution dans le navigateur ou le conditionnement dans une PWA, mais dans cette dernière, le développeur a plus de contrôle sur ce qui est stocké localement.
Le rendu d’interfaces à partir de HTML est une activité tellement récurrente que le moteur est généralement un composant logiciel distinct, présent dans le système d’exploitation. Sa présence en tant que composant séparé permet à différentes applications de l’incorporer sans avoir à l’intégrer dans le paquetage de l’application. Ce modèle délègue également la maintenance du moteur de rendu au système d’exploitation, ce qui facilite les mises à jour. Il est très important de maintenir à jour un composant aussi crucial afin d’éviter d’éventuelles défaillances.
Quelle que soit leur méthode de livraison, les applications écrites en HTML s’exécutent sur une couche d’abstraction créée par le moteur, qui fonctionne comme un environnement d’exécution isolé. En particulier, dans le cas d’un client qui s’exécute sur le navigateur, l’application n’a à sa disposition que les ressources offertes par le navigateur. Les fonctions de base, telles que l’interaction avec les éléments de la page et la demande de fichiers par HTTP, sont toujours disponibles. Les ressources susceptibles de contenir des informations sensibles, telles que l’accès aux fichiers locaux, à la localisation géographique, à la caméra et au microphone, nécessitent une autorisation explicite de l’utilisateur avant que l’application ne puisse les utiliser.
Langages d’un client Web
L’élément central d’un client d’application web qui s’exécute sur le serveur est le document HTML. En plus de présenter de manière structurée les éléments d’interface que le navigateur affiche, le document HTML contient les adresses de tous les fichiers nécessaires à la présentation et au fonctionnement corrects du client.
Le HTML seul n’offre pas une grande polyvalence pour construire des interfaces plus élaborées et ne dispose pas de fonctions de programmation à usage général. Pour cette raison, un document HTML qui doit fonctionner comme une application client est toujours accompagné d’un ou plusieurs ensembles de CSS et de JavaScript.
Le CSS peut être fourni sous forme de fichier séparé ou directement dans le fichier HTML lui-même. L’objectif principal du CSS est d’ajuster l’apparence et la disposition des éléments de l’interface HTML. Bien que cela ne soit pas strictement nécessaire, les interfaces plus sophistiquées nécessitent généralement des modifications des propriétés CSS des éléments pour répondre à leurs besoins.
JavaScript est un composant pratiquement indispensable. Les procédures écrites en JavaScript répondent à des événements dans le navigateur. Ces événements peuvent être provoqués par l’utilisateur ou être non interactifs. Sans JavaScript, un document HTML est pratiquement limité au texte et aux images. L’utilisation de JavaScript dans les documents HTML permet d’étendre l’interactivité au-delà des hyperliens et des formulaires, faisant de la page affichée par le navigateur une interface d’application conventionnelle.
JavaScript est un langage de programmation polyvalent, mais il est principalement utilisé dans les applications web. Les fonctionnalités de l’environnement d’exécution du navigateur sont accessibles par des mots-clés JavaScript, utilisés dans un script pour effectuer l’opération souhaitée. Le terme document
, par exemple, est utilisé dans le code JavaScript pour désigner le document HTML associé au code JavaScript. Dans le contexte du langage JavaScript, le document
est un objet global doté de propriétés et de méthodes qui peuvent être utilisées pour obtenir des informations de n’importe quel élément du document HTML. Plus important encore, vous pouvez utiliser l’objet document
pour modifier ses éléments et les associer à des actions personnalisées écrites en JavaScript.
Une application client basée sur les technologies web est multiplateforme, car elle peut fonctionner sur tout appareil doté d’un navigateur web compatible.
Le fait d’être confiné au navigateur impose toutefois des limites aux applications web par rapport aux applications natives. L’intermédiation effectuée par le navigateur permet une programmation de plus haut niveau et accroît la sécurité, mais elle augmente également le traitement et la consommation de la mémoire.
Les développeurs travaillent continuellement sur les navigateurs pour offrir davantage de fonctionnalités et améliorer les performances des applications JavaScript, mais il existe des aspects intrinsèques à l’exécution de scripts tels que JavaScript qui leur imposent un désavantage par rapport aux programmes natifs pour le même matériel.
WebAssembly est une fonctionnalité qui améliore considérablement les performances des applications JavaScript exécutées dans le navigateur. WebAssembly est un type de JavaScript compilé qui produit un code source écrit dans un langage plus efficace et de plus bas niveau, tel que le langage C. WebAssembly peut accélérer principalement les activités gourmandes en ressources processeur, car il évite une grande partie de la traduction effectuée par le navigateur lors de l’exécution d’un programme écrit en JavaScript classique.
Quels que soient les détails de la mise en œuvre de l’application, tous les fichiers de code HTML, CSS, JavaScript et multimédia doivent d’abord être obtenus du serveur. Le navigateur obtient ces fichiers comme une page Internet, c’est-à-dire avec une adresse à laquelle le navigateur accède.
Une page web qui sert d’interface à une application web ressemble à un document HTML ordinaire, mais ajoute des comportements supplémentaires. Sur les pages classiques, l’utilisateur est dirigé vers une autre page après avoir cliqué sur un lien. Les applications web peuvent présenter leur interface et répondre aux événements de l’utilisateur sans charger de nouvelles pages dans la fenêtre du navigateur. La modification de ce comportement standard dans les pages HTML se fait via la programmation JavaScript.
Un client de messagerie web, par exemple, affiche les messages et passe d’un dossier de messages à un autre sans quitter la page. Cela est possible parce que le client utilise JavaScript pour réagir aux actions de l’utilisateur et faire les requêtes appropriées au serveur. Si l’utilisateur clique sur le sujet d’un message dans la boîte de réception, un code JavaScript associé à cet événement demande le contenu de ce message au serveur (en utilisant l’appel API correspondant). Dès que le client reçoit la réponse, le navigateur affiche le message dans la partie appropriée de la même page. Les différents clients webmail peuvent adopter des stratégies différentes, mais ils utilisent tous ce même principe.
Par conséquent, en plus de fournir au navigateur les fichiers qui composent le client, le serveur doit également être en mesure de traiter des requêtes telles que celle du client webmail, lorsqu’il demande le contenu d’un message spécifique. Chaque requête que le client peut faire a une procédure prédéfinie pour répondre sur le serveur, dont l’API peut définir différentes méthodes pour identifier à quelle procédure la requête se réfère. Les méthodes les plus courantes sont les suivantes :
-
Les adresses, par le biais d’un localisateur uniforme de ressource (URL : Uniform Resource Locator)
-
Les champs de l’en-tête HTTP
-
Les méthodes GET/POST
-
Les WebSockets
Une méthode peut être plus adaptée qu’une autre, en fonction de l’objet de la requête et d’autres critères pris en compte par le développeur. En général, les applications web utilisent une combinaison de méthodes, chacune dans une circonstance spécifique.
Le modèle REST (Representational State Transfer) est largement utilisé pour la communication dans les applications web, car il repose sur les méthodes de base disponibles dans HTTP. L’en-tête d’une requête HTTP commence par un mot clé qui définit l’opération de base à effectuer : GET
, POST
, PUT
, DELETE
, etc., accompagné d’une URL correspondante où l’action sera appliquée. Si l’application nécessite des opérations plus spécifiques, avec une description plus détaillée de l’opération demandée, le protocole GraphQL peut être un choix plus approprié.
Les applications développées à l’aide du modèle client/serveur sont sujettes à des instabilités dans la communication. Pour cette raison, l’application cliente doit toujours adopter des stratégies de transfert de données efficaces pour favoriser sa cohérence et ne pas nuire à l’expérience utilisateur.
Côté serveur
Bien qu’il soit l’acteur principal d’une application web, le serveur est le côté passif de la communication, se contentant de répondre aux requêtes formulées par le client. Dans le jargon du web, le serveur peut désigner la machine qui reçoit les requêtes, le programme qui traite spécifiquement les requêtes HTTP ou le script destinataire qui produit une réponse à la requête. Cette dernière définition est la plus pertinente dans le contexte de l’architecture des applications web, mais elles sont toutes étroitement liées. Bien qu’ils ne soient que partiellement dans le champ d’action du développeur de serveur d’applications, la machine, le système d’exploitation et le serveur HTTP ne peuvent être ignorés, car ils sont fondamentaux pour le fonctionnement du serveur d’applications et se croisent souvent.
Traitement des chemins à partir de requêtes
Les serveurs HTTP, tels que Apache et NGINX, nécessitent généralement des modifications de configuration spécifiques pour répondre aux besoins de l’application. Par défaut, les serveurs HTTP traditionnels associent directement le chemin indiqué dans la requête à un fichier du système de fichiers local. Si le serveur HTTP d’un site web conserve ses fichiers HTML dans le répertoire /srv/www
, par exemple, une requête avec le chemin /en/about.html
recevra le contenu du fichier /srv/www/en/about.html
comme réponse, si le fichier existe. Les sites web plus sophistiqués, et surtout les applications web, exigent des traitements personnalisés pour différents types de requêtes. Dans ce scénario, une partie de la mise en œuvre de l’application consiste à modifier les paramètres du serveur HTTP pour répondre aux exigences de l’application.
Il existe également des frameworks qui permettent d’intégrer la gestion des requêtes HTTP et l’implémentation du code de l’application en un seul endroit, ce qui permet au développeur de se concentrer davantage sur l’objectif de l’application que sur les détails de la plate-forme. Dans Node.js Express, par exemple, tout le mappage des requêtes et la programmation correspondante sont mis en œuvre en utilisant JavaScript. Comme la programmation des clients est généralement effectuée en JavaScript, de nombreux développeurs considèrent que c’est une bonne idée, du point de vue de la maintenance du code, d’utiliser le même langage pour le client et pour le serveur. Les autres langages couramment utilisés pour mettre en œuvre le côté serveur, que ce soit dans les frameworks ou dans les serveurs HTTP traditionnels, sont PHP, Python, Ruby, Java et C#.
Systèmes de gestion des bases de données
La manière dont les données reçues ou demandées par le client sont stockées sur le serveur est laissée à la discrétion de l’équipe de développement, mais il existe des directives générales qui s’appliquent à la plupart des cas. Il est pratique de conserver le contenu statique : images, code JavaScript et CSS qui ne changent pas à court terme sous forme de fichiers classiques, soit sur le propre système de fichiers du serveur, soit distribué sur un réseau de diffusion de contenu (CDN : Content Delivery Network). D’autres types de contenu, comme les messages électroniques d’une application de messagerie web, les détails d’un produit dans une application d’achat et les journaux de transactions, sont plus facilement stockés dans un système de gestion de base de données (SGBD).
Le type le plus traditionnel de système de gestion de base de données est la base de données relationnelle. Dans celle-ci, le concepteur de l’application définit les tables de données et le format d’entrée accepté par chaque table. L’ensemble des tables de la base de données contient toutes les données dynamiques consommées et produites par l’application. Une application de shopping, par exemple, peut avoir une table qui contient une entrée avec les détails de chaque produit dans le magasin et une table qui enregistre les articles achetés par un utilisateur. La table des articles achetés contient des références aux entrées de la table des produits, créant ainsi des relations entre les tables. Cette approche peut optimiser le stockage et l’accès aux données, ainsi que permettre des requêtes dans des tables combinées en utilisant le langage adopté par le système de gestion de base de données. Le langage de base de données relationnel le plus populaire est le langage de requête structuré (Structured Query Language : SQL, prononcé "sequel"), adopté par les bases de données open source SQLite, MySQL, MariaDB et PostgreSQL.
Une alternative aux bases de données relationnelles est une forme de base de données qui ne nécessite pas une structure rigide pour les données. Ces bases de données sont appelées bases de données non relationnelles ou simplement NoSQL. Bien qu’elles puissent intégrer des fonctionnalités similaires à celles des bases de données relationnelles, l’objectif est de permettre une plus grande flexibilité dans le stockage et l’accès aux données stockées, en confiant la tâche de traiter ces données à l’application elle-même. MongoDB, CouchDB et Redis sont des systèmes de gestion de bases de données non relationnelles courants.
Maintenance du contenu
Quel que soit le modèle de base de données adopté, les applications doivent ajouter des données et probablement les mettre à jour au cours de leur durée de vie. Dans certaines applications, comme le webmail, les utilisateurs fournissent eux-mêmes des données à la base de données lorsqu’ils utilisent le client pour envoyer et recevoir des messages. Dans d’autres cas, comme dans l’application de shopping, il est important de permettre aux responsables de l’application de modifier la base de données sans avoir à recourir à la programmation. De nombreuses organisations adoptent donc une sorte de système de gestion de contenu (CMS : Content Management System), qui permet aux utilisateurs non techniques d’administrer l’application. Par conséquent, pour la plupart des applications web, il est nécessaire de mettre en œuvre au moins deux types de clients : un client non privilégié, utilisé par les utilisateurs ordinaires, et des clients privilégiés, utilisés par des utilisateurs spéciaux pour maintenir et mettre à jour les informations présentées par l’application.
Exercices guidés
-
Quel langage de programmation est utilisé avec le HTML pour créer des applications web clientes ?
-
En quoi l’accès à une application web diffère-t-il de celui d’une application native ?
-
En quoi une application web diffère-t-elle d’une application native en matière d’accès au matériel local ?
-
Citez une caractéristique du client d’une application web qui le distingue d’une page web ordinaire.
Exercices d’exploration
-
Quelle fonction les navigateurs modernes offrent-ils pour pallier les mauvaises performances des clients d’applications web à forte utilisation du processeur ?
-
Si une application web utilise le modèle REST pour la communication client/serveur, quelle méthode HTTP doit être utilisée lorsque le client demande au serveur d’effacer une ressource spécifique ?
-
Citer cinq langages de script pris en charge par le serveur HTTP Apache.
-
Pourquoi les bases de données non relationnelles sont-elles considérées comme plus faciles à maintenir et à mettre à niveau que les bases de données relationnelles ?
Résumé
Cette leçon couvre les concepts et les normes de la technologie et de l’architecture du développement web. Le principe est simple : le navigateur web exécute l’application cliente, qui communique avec l’application centrale exécutée dans le serveur. Bien que simple dans son principe, les applications web doivent combiner de nombreuses technologies pour adopter le principe de l’informatique client et serveur sur le Web. La leçon passe en revue les concepts suivants :
-
Rôle des navigateurs et des serveurs web.
-
Technologies et normes de développement web courantes.
-
Comment les clients web peuvent communiquer avec le serveur.
-
Types de serveurs web et de serveurs de bases de données.
Réponses aux exercices guidés
-
Quel langage de programmation est utilisé avec le HTML pour créer des applications web clientes ?
JavaScript
-
En quoi l’accès à une application web diffère-t-il de celui d’une application native ?
Une application web n’est pas installée. Au lieu de cela, certaines de ses parties s’exécutent sur le serveur et l’interface client s’exécute dans un navigateur web ordinaire.
-
En quoi une application web diffère-t-elle d’une application native en matière d’accès au matériel local ?
Tous les accès aux ressources locales, comme le stockage, les caméras ou les microphones, sont gérés par le navigateur et nécessitent une autorisation explicite de l’utilisateur pour fonctionner.
-
Citez une caractéristique du client d’une application web qui le distingue d’une page web ordinaire.
L’interaction avec les pages web traditionnelles se limite essentiellement aux hyperliens et à l’envoi de formulaires, tandis que les clients des applications web sont plus proches d’une interface d’application conventionnelle.
Réponses aux exercices d’exploration
-
Quelle fonction les navigateurs modernes offrent-ils pour pallier les mauvaises performances des clients d’applications web à forte utilisation du processeur ?
Les développeurs peuvent utiliser WebAssembly pour mettre en œuvre les parties de l’application client qui requièrent une forte utilisation du processeur. Le code WebAssembly est généralement plus performant que le JavaScript traditionnel, car il nécessite moins de traduction d’instructions.
-
Si une application web utilise le modèle REST pour la communication client/serveur, quelle méthode HTTP doit être utilisée lorsque le client demande au serveur d’effacer une ressource spécifique ?
REST s’appuie sur des méthodes standards HTTP, il devrait donc utiliser la méthode standard
DELETE
dans ce cas. -
Citer cinq langages de script pris en charge par le serveur HTTP Apache.
PHP, Go, Perl, Python, et Ruby.
-
Pourquoi les bases de données non relationnelles sont-elles considérées comme plus faciles à maintenir et à mettre à niveau que les bases de données relationnelles ?
Contrairement aux bases de données relationnelles, les bases de données non relationnelles n’exigent pas que les données correspondent à des structures rigides prédéfinies, ce qui facilite la mise en œuvre des changements dans les structures de données sans affecter les données existantes.