Framework Web

Un framework Web ou framework d'application Web est un framework logiciel conçu pour prendre en charge le développement d'applications Web, notamment des services Web, des ressources Web et des API Web. Les frameworks Web fournissent un moyen standard de créer et de déployer des applications Web sur le World Wide Web. Les frameworks Web visent à automatiser les mécanismes les plus courants du développement Web. Par exemple, de nombreux frameworks Web fournissent des bibliothèques pour l'accès aux bases de données, les moteurs de rendu et la gestion des sessions, et ils favorisent souvent la réutilisation du code^[1]. Bien qu'ils ciblent souvent le développement de sites Web dynamiques, ils s'appliquent également aux sites Web statiques^[2].

Histoire

Comme le World Wide Web n'était par conception pas intrinsèquement dynamique, les premiers hypertextes consistaient en des fichiers texte HTML codés à la main qui étaient publiés sur des serveurs Web. Toute modification des pages publiées devaient être effectuée à la main par son auteur et aucune information ne pouvait être mise à jour en temps réel. En 1993, la norme Common Gateway Interface (CGI) a été introduite pour interfacer des applications externes avec des serveurs Web, afin de fournir une page Web dynamique reflétant les entrées de l'utilisateur^[3].

Cependant, les implémentations originales de l'interface CGI avaient généralement des effets négatifs sur la charge du serveur, car chaque demande démarrait un processus séparé^[4] et il est apparu nécessaire d'utiliser des processus persistants pour offrir une amélioration générale des performances^{[réf. nécessaire]}.

En 1995 apparaissent des environnements de développement basé sur des langages entièrement intégrés au serveur web. Ces langages s'intègrent directement dans le fichier html et sont interprétés par un module du serveur web avant l'envoi de la page au navigateur. Parmi les langages les plus utilisés à cette époque figurent ColdFusion, PHP, Java Server Faces et Active Server Pages^{[réf. nécessaire]}. Ils permettent alors une modification d'abord locale d'informations au sein de certaines pages.

Bien que la grande majorité des langages de création de pages Web dynamiques disposent de bibliothèques pour faciliter les tâches courantes, les applications Web nécessitent souvent des bibliothèques spécifiques pour des tâches particulières, telles que la création de code HTML. Des bibliothèques spécifiques à ces tâches ont alors été développées.

À la fin des années 1990, des frameworks dit « full stack » ont commencé à apparaître, en rassemblant souvent plusieurs bibliothèques utiles pour le développement Web dans une seule pile logicielle cohérente que les développeurs Web pouvaient utiliser. Des exemples de ceci incluent ASP. NET, Java EE, WebObjects, web2py, OpenACS, Catalyst, Mojolicious, Ruby on Rails, Laravel, Grails, Django, Zend Framework, Sails.js, Yii^[5], CakePHP^[6], et Symfony^{[réf. nécessaire]}.

Types d'architectures de cadre

La plupart des frameworks Web sont basés sur le modèle modèle-vue-contrôleur (MVC)^{[réf. nécessaire]}. Certaines variations existent néanmoins quant à l'interprétation de la répartition des tâches dans ce modèle^[7].

Modèle-vue-contrôleur (MVC)

De nombreux frameworks suivent le modèle architectural MVC pour séparer le modèle de données des règles métier (le "contrôleur") et de l'interface utilisateur (la "vue"). Cette séparation est généralement considéré comme une bonne pratique car elle modularise le code, favorise sa réutilisation et permet l'application de plusieurs interfaces sur le même moteur. Dans les applications Web, cela permet de présenter différentes vues, par exemple en servant différentes pages Web pour les navigateurs mobiles par rapport aux navigateurs de bureau, ou en fournissant des interfaces de service Web lisibles par machine.

Basé sur le push vs basé sur le pull

La plupart des frameworks MVC suivent une architecture basée sur le push également appelée « basée sur l'action ». Ces frameworks utilisent des actions qui effectuent le traitement requis, puis « poussent » les données vers la couche de vue pour afficher les résultats^[8]. Django, Ruby on Rails, Symfony, Spring MVC, Stripes, Sails.js, CodeIgniter^[9] sont de bons exemples de cette architecture. Une alternative est l'architecture basée sur le pull, parfois également appelée « basée sur les composants ». Ces frameworks commencent par la couche de vue, qui peut ensuite « extraire » les résultats de plusieurs contrôleurs selon les besoins. Dans cette architecture, plusieurs contrôleurs peuvent être impliqués dans une seule vue. Lift, Tapestry, JBoss Seam, Jakarta Server Faces et Wicket sont des exemples d'architectures basées sur l'extraction. Play, Struts, RIFE et ZK prennent en charge les appels de contrôleur d'application push et pull^{[réf. nécessaire]}.

Organisation à trois couches

Dans une organisation à trois couches, les applications sont structurées autour de trois couches physiques : client, application et base de données^{[10],[11],[12],[13]}. La base de données est généralement un SGBDR. L'application contient la logique métier, s'exécute sur un serveur et communique avec le client via HTTP^[14]. Le client sur les applications Web est un navigateur Web qui exécute le code HTML généré par la couche application^[15],[16]. Le terme ne doit pas être confondu avec MVC, où, contrairement à l'architecture à trois niveaux, il est considéré comme une bonne pratique de garder la logique métier à l'écart du contrôleur, la "couche intermédiaire"^[17],[18].

Applications web

Les frameworks sont conçus pour prendre en charge la construction d'applications web basées sur un langage de programmation unique, allant des outils à usage général tels que Zend Framework et Ruby on Rails, qui augmentent les capacités d'un langage spécifique, aux packages programmables en langage natif construits autour de une application utilisateur spécifique, telle que des systèmes de gestion de contenu (CMS), des applications sociales, portails ou places de marché en ligne^[19].

Frameworks Web à usage général

Les frameworks Web doivent fonctionner selon les règles architecturales des navigateurs et des protocoles tels que HTTP, qui est sans état. Les pages Web sont servies par un serveur et peuvent ensuite être modifiées par le navigateur à l'aide de JavaScript. Les frameworks peuvent donc effectuer les traitements et mises à jour de pages côté serveur ou côté client.

Les modifications côté serveur nécessitent généralement que la page soit actualisée dans le navigateur, mais permettent d'utiliser n'importe quelle langage et d'utiliser plus de puissance de calcul. Les modifications côté client permettent à la page d'être mise à jour par morceaux, ce qui permet une plus grande similarité avec une application de bureau, mais sont limités à JavaScript et exécutés dans le navigateur de l'utilisateur, qui a une puissance de calcul limitée. Un mélange des deux est parfois utilisé^[20]. Les applications qui utilisent intensivement JavaScript et n'actualisent que des parties de la page sont appelées applications monopage parce que la page html n'est chargée qu'une fois par le navigateur. Elles utilisent généralement un framework Web JavaScript côté client pour organiser le code^{[réf. nécessaire]}.

Frameworks côté serveur

• Apache Wicket
• ASP.NET Core
• CakePHP
• Catalyst
• CodeIgniter
• CppCMS
• Django
• Flask
• Jam.py
• Yii
• Laravel
• Mojolicious
• Ruby on rails
• Sails.js
• Symfony
• Spring
• Zend

Frameworks côté client

Les exemples incluent Backbone.js, AngularJS, Angular, EmberJS, ReactJS, jQuery UI, Svelte et Vue.js^[21].

Fonctionnalités

Les frameworks définissent généralement le flux de contrôle d'un programme et permettent à l'utilisateur du framework de "s'insérer" dans ce flux en utilisant divers événements^[22] ou en insérant du code à des moments précis de l'exécution. Ce modèle d'inversion de contrôle est considéré comme un principe de définition d'un framework et profite au code en appliquant un flux commun pour une équipe dans laquelle les modifications de chacun peuvent être uniformes^[22]. Par exemple, certains "microframeworks" populaires tels que Sinatra ou Express.js autorisent les insertions en "middleware" avant et après les requêtes HTTP. Ces fonctions middleware peuvent avoir n'importe quelle fonction comme par exemple la journalisation, l'authentification et la gestion des sessions, ainsi que la redirection^[23].

Système de modèles Web

Mise en cache

La mise en cache Web est la mise en cache des documents Web afin de réduire l'utilisation bande passante, la charge du serveur et la latence. Un cache Web stocke des copies des documents qui le traversent ; les demandes ultérieures peuvent être satisfaites à partir du cache si certaines conditions sont remplies. Certains frameworks d'application fournissent des mécanismes pour mettre en cache les documents et contourner diverses étapes de préparation de la page, telles que l'accès à la base de données ou l'interprétation du modèle^{[réf. nécessaire]}.

Sécurité

Certains frameworks Web sont livrés avec des frameworks d'authentification et d'autorisation qui permettent au serveur Web d'identifier les utilisateurs de l'application et de restreindre l'accès aux fonctions en fonction de certains critères définis. Drupal est un exemple qui fournit aux pages un accès basé sur les rôles et une interface Web pour créer des utilisateurs et leur attribuer des rôles^{[réf. nécessaire]}.

Accès à la base de données

De nombreux frameworks Web créent une API unifiée vers un backend de base de données, permettant aux applications Web de fonctionner avec une variété de bases de données sans modification de code et permettant aux programmeurs de travailler avec des concepts de niveau supérieur. De plus, certains frameworks orientés objet contiennent des outils de mapping pour fournir un mapping objet-relationnel, qui fait correspondre des objets avec des collections^[24].

Certains frameworks minimisent la configuration des applications Web en utilisant l'introspection et/ou en suivant des conventions admises. Par exemple, de nombreux frameworks Java utilisent Hibernate comme couche de persistance qui peut générer un schéma de base de données au moment de l'exécution. Cela permet au concepteur d'application de concevoir des objets métier sans avoir besoin de définir explicitement un schéma de base de données. Les frameworks tels que Ruby on Rails peuvent également fonctionner en sens inverse, c'est-à-dire définir les propriétés des objets du modèle lors de l'exécution sur la base d'un schéma de base de données^[24].

Les autres fonctionnalités que les frameworks Web peuvent fournir incluent le support de transactions^[25] et les outils de migration de base de données^[24].

Routage d'URL

La fonction de mapping ou de routage d'URL d'un framework est le mécanisme par lequel le framework interprète les URL. Certains frameworks, tels que Drupal et Django, comparent l'URL fournie à des modèles prédéterminés à l'aide d'expressions régulières, tandis que d'autres utilisent des techniques de réécriture pour traduire l'URL fournie en une URL que le moteur sous-jacent reconnaîtra. Une autre technique est celle de la traversée de graphe telle qu'utilisée par Zope, où une URL est décomposée en étapes qui traversent un graphe d'objets (de modèles et de vues)^{[réf. nécessaire]}.

Un système de mapping d'URL qui utilise la correspondance de modèles ou la réécriture pour acheminer et gérer les requêtes permet d'utiliser des « URL propres » plus courtes, augmentant ainsi la simplicité du site et permettant une meilleure indexation par les moteurs de recherche. Par exemple, une URL qui se termine par "/page.cgi?cat=science&topic=physics" peut être changée simplement en "/page/science/physics". Cela facilite la mémorisation, la lecture et l'écriture de l'URL, et fournit aux moteurs de recherche de meilleures informations sur la disposition structurelle du site. Une approche de traversée de graphes a également tendance à aboutir à la création d'URL conviviales. Une URL plus courte telle que "/page/science" a tendance à exister par défaut car il s'agit simplement d'une forme plus courte de la traversée plus longue vers "/page/science/physique".^{[réf. nécessaire]}

AJAX

Ajax, abréviation de « JavaScript et XML asynchrones », est une technique de développement Web permettant de créer des applications. L'intention est de rendre les pages Web plus réactives en échangeant de petites quantités de données avec le serveur en arrière-plan, de sorte que la page Web entière n'ait pas à être rechargée chaque fois que l'utilisateur demande une modification. Ceci est destiné à augmenter l'interactivité, la vitesse, la maintenabilité et la convivialité d'une page Web^[26].

En raison de la complexité de la programmation Ajax en JavaScript, de nombreux frameworks Ajax traitent exclusivement du support Ajax. Certains frameworks Ajax sont même intégrés dans des frameworks plus larges. Par exemple, la bibliothèque JavaScript jQuery est incluse dans Ruby on Rails^{[réf. nécessaire]}.

Avec l'intérêt accru pour le développement d'applications Web riches dites " Web 2.0 ", la complexité de la programmation utilisant Ajax et JavaScript est devenue si évidente que la technologie des compilateurs est intervenue, pour permettre aux développeurs de coder dans des langages de haut niveau tels que Java, Python et Rubis. Le premier de ces compilateurs était Morfik suivi de Google Web Toolkit, avec des ports vers Python et Ruby sous la forme de Pyjs et RubyJS après quelque temps après. Ces compilateurs et leurs bibliothèques d'ensembles de widgets associés rendent le développement d'applications Ajax rich media beaucoup plus proche de celui du développement d'applications de bureau^{[réf. nécessaire]}.

Services Web

Certains frameworks fournissent des outils pour créer et fournir des services Web. Ces utilitaires peuvent offrir des outils similaires au reste de l'application Web^[27]. Ceci se fait en général par le biais d'API Web.

Ressources Web

Un certain nombre de frameworks Web 2.0 RESTful plus récents fournissent désormais une infrastructure d'architecture orientée ressources (ROA) pour la création de collections de ressources dans une sorte d'ontologie de Web sémantique, basée sur les concepts de Resource Description Framework (RDF)^{[réf. nécessaire]}.

Voir aussi

• Comparaison des frameworks Web basés sur JavaScript (en)
• Comparaison des frameworks d'applications web
• Serveur d'applications
• Application framework (en)
• Sécurité des applications (en)
• Convention plutôt que configuration
• Ne vous répétez pas (DRY)
• Liste de web service frameworks (en)
• Rich Internet application (obsolète)
• Liste de rich web application frameworks (en)
• Pile technologique
• Mobile development framework (en)

Références

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Web framework » (voir la liste des auteurs).

1. Multiple (wiki), « Web application framework » [archive du 23 juillet 2015], sur Docforge
2. « Top Open-Source Static Site Generators », sur StaticGen
3. « CGI: Common Gateway Interface » [archive du 9 avril 2009]
4. (en-US) « CGI », www.ibm.com (consulté le 7 mai 2021)
5. « Yii PHP Framework »
6. « CakePHP »
7. (en) « Django », sur Django Project (consulté le 30 avril 2023)
8. Kris Thomson, « Clarification on MVC= Pull and MVC Push », 29 octobre 2003 (consulté le 29 juillet 2007)
9. « What are the fundamental differences between Struts and JSF », Struts.apache.org, 14 février 2011 (consulté le 14 juin 2013)
10. Microsoft, « Three-tiered distribution » (consulté le 19 septembre 2011)
11. Oracle, « clustering_concepts_10en » (consulté le 19 septembre 2011)
12. Robert R. Perkoski, « Introduction to Web Development » [archive du 7 novembre 2013]
13. IBM, « Using Client Access Express in a three tier environment » (consulté le 19 septembre 2011)
14. Oracle, « Understanding the Three-Tier Architecture » (consulté le 19 septembre 2011)
15. Microsoft, « Pragmatic Architecture: Layering » (consulté le 19 septembre 2011)
16. Arokia, « 3-Tier Web Architecture » (consulté le 19 septembre 2011)
17. « ASP.NET MVC Controller Best Practices » [archive du 11 octobre 2011] (consulté le 19 septembre 2011)
18. Jamis Buck, « Skinny Controller, Fat Model » [archive du 16 mai 2015]
19. (en) « Getting Started With Web Frameworks », Wired Magazine,‎ février 2010 (lire en ligne, consulté le 2 avril 2018)
20. Mel KLIMUSHYN, « Web Application Architecture – Client-Side vs. Server-Side », Atomic Spin, 6 avril 2015 (consulté le 6 mars 2016)
21. (en-US) « AngularJS vs. Backbone.js vs. Ember.js », www.airpair.com (consulté le 4 juin 2016)
22. Martin Fowler, « bliki: InversionOfControl », martinfowler.com (consulté le 6 mars 2016)
23. Qiang Xue, « Capital One Engineering – Philosophies that Shaped Successful Frameworks », www.capitalone.io (consulté le 6 mars 2016)
24. « Active Record Basics », Ruby on Rails (consulté le 20 mars 2021) : « Object Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system...Active Record automatically creates methods to allow an application to read and manipulate data stored within its tables. »
25. « Active Record Transactions », Ruby on Rails (consulté le 20 mars 2021)
26. « What is AJAX », www.dlsweb.rmit.edu.au (consulté le 7 mai 2021)
27. E.M. Maximilien, « Web Services on Rails: Using Ruby and Rails for Web Services Development and Mashups », IEEE Xplore, Chicago,‎ 19 décembre 2006 (ISBN 0-7695-2669-1, DOI 10.1109/ICWS.2006.139, lire en ligne)

• Portail de l’informatique