La mise en forme de cet article est à améliorer (avril 2023).

La mise en forme du texte ne suit pas les recommandations de Wikipédia : il faut le « wikifier ».

Comment faire ?

Les points d'amélioration suivants sont les cas les plus fréquents. Le détail des points à revoir est peut-être précisé sur la page de discussion.

• Les titres sont pré-formatés par le logiciel. Ils ne sont ni en capitales, ni en gras.
• Le texte ne doit pas être écrit en capitales (les noms de famille non plus), ni en gras, ni en italique, ni en « petit »…
• Le gras n'est utilisé que pour surligner le titre de l'article dans l'introduction, une seule fois.
• L'italique est rarement utilisé : mots en langue étrangère, titres d'œuvres, noms de bateaux, etc.
• Les citations ne sont pas en italique mais en corps de texte normal. Elles sont entourées par des guillemets français : « et ».
• Les listes à puces sont à éviter, des paragraphes rédigés étant largement préférés. Les tableaux sont à réserver à la présentation de données structurées (résultats, etc.).
• Les appels de note de bas de page (petits chiffres en exposant, introduits par l'outil «  Source ») sont à placer entre la fin de phrase et le point final^{[comme ça]}.
• Les liens internes (vers d'autres articles de Wikipédia) sont à choisir avec parcimonie. Créez des liens vers des articles approfondissant le sujet. Les termes génériques sans rapport avec le sujet sont à éviter, ainsi que les répétitions de liens vers un même terme.
• Les liens externes sont à placer uniquement dans une section « Liens externes », à la fin de l'article. Ces liens sont à choisir avec parcimonie suivant les règles définies. Si un lien sert de source à l'article, son insertion dans le texte est à faire par les notes de bas de page.
• La présentation des références doit suivre les conventions bibliographiques. Il est recommandé d'utiliser les modèles {{Ouvrage}}, {{Chapitre}}, {{Article}}, {{Lien web}} et/ou {{Bibliographie}}. Le mode d'édition visuel peut mettre en forme automatiquement les références.
• Insérer une infobox (cadre d'informations à droite) n'est pas obligatoire pour parachever la mise en page.

Pour une aide détaillée, merci de consulter Aide:Wikification.

Si vous pensez que ces points ont été résolus, vous pouvez retirer ce bandeau et améliorer la mise en forme d'un autre article.

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].

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]}.

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].

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ée 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.

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]}.

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].

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].

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]}.

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

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

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].

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]}.

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]}.

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].

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, 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]}.

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.

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]}.

• 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)

• (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).

• Portail de l’informatique