Comment et pourquoi les frameworks d'applications Web modernes ont-ils évolué pour découpler les itinéraires d'URL du système de fichiers?

Par rapport à il y a environ 10 ans, j'ai noté une évolution vers des frameworks utilisant le style de routage qui dissocie le chemin de l'URL du système de fichiers. Ceci est généralement accompli à l'aide d'un modèle de contrôleur frontal.

À savoir, quand auparavant, le chemin de l'URL était mappé directement sur le système de fichiers et reflétait donc les fichiers et dossiers exacts sur le disque. De nos jours, les chemins d'URL réels sont programmés pour être dirigés vers des classes spécifiques via la configuration et, en tant que tels, ne reflètent plus le fichier. dossier système et structure de fichier.

Question

Comment et pourquoi cela est-il devenu banal? Comment et pourquoi a-t-on décidé qu'il était "préférable" au point où l'approche autrefois banale du traitement direct au fichier a effectivement été abandonnée?

Autres réponses

Il y a une réponse similaire ici qui va un peu dans le concept de route, avec quelques avantages et inconvénients: Avec les frameworks PHP, pourquoi utilise-t-on le concept de "route"?

Mais il ne traite pas des aspects des changements historiques, ni comment ni pourquoi ces changements se sont produits progressivement, où de nouveaux projets utilisent aujourd'hui ce nouveau modèle de style de routage et où le traitement direct dans un fichier est obsolète ou abandonné.

En outre, la plupart des avantages et inconvénients mentionnés ne semblent pas être suffisamment importants pour justifier un tel changement mondial. Le seul avantage que je peux constater à l’origine de cette modification est peut-être de cacher le système de fichiers / dossiers à l’utilisateur final, ainsi que l’absence de ?param=value&param2=value, ce qui donne aux URL un aspect plus pur. Mais étaient-ce la seule raison du changement? Et si oui, pourquoi ces raisons étaient- elles derrière?

Exemples:

Je connais très bien les frameworks PHP et de nombreux frameworks modernes utilisent cette approche de routage découplé. Pour que cela fonctionne, vous configurez la réécriture d'URL dans Apache ou un serveur Web similaire, afin que la fonctionnalité d'application Web ne soit généralement plus déclenchée via un chemin d'URL direct vers un fichier.

Zend Expressive

https://docs.zendframework.com/zend-expressive/features/router/aura/
https://docs.zendframework.com/zend-expressive/features/router/fast-route/
https: //docs.zendframework. com / zend-expressive / features / router / zf2 /

Zend Framework

https://docs.zendframework.com/zend-mvc/routing/

Laravel

https://laravel.com/docs/5.5/routing

CakePHP

https://book.cakephp.org/3.0/en/development/routing.html

Dans sa forme la plus élémentaire, un site Web sert des fichiers statiques. Le choix le plus évident est de mapper le chemin de l'URL sur un chemin de fichier. il s’agit essentiellement d’un site FTP en lecture seule.

Ensuite, les gens voulaient changer le contenu de la page avec des scripts. Le moyen le plus simple consiste à incorporer un langage de script dans la page et à l'exécuter via un interpréteur. Encore une fois, étant donné le chemin existant -> le routage du chemin du fichier, c'était assez simple.

Mais en réalité, vous utilisez ce fichier comme argument pour l’interprète. Vous devez identifier quand la demande concerne un fichier statique et quand il s'agit de quelque chose que vous devez interpréter.

Une fois que vous commencez à utiliser des langages compilés plus avancés, vous êtes encore plus dissocié de l'emplacement du fichier.

De plus, votre serveur Web met déjà en cache des fichiers statiques et effectue toutes sortes d’optimisations, ce qui signifie que frapper le système de fichiers est l’exception plutôt que la règle. À ce stade, l'ancien chemin du système de fichiers de liaison constitue davantage un obstacle qu'une aide.

Mais je pense que le vrai changement est survenu lorsque les utilisateurs ont voulu supprimer l’extension de fichier du chemin. Obtenir myPage.asp ou myPage.php était quelque chose qui confondait les gens «normaux» et entravait le référencement.

Parce que l'utilisateur voit le chemin, il fait désormais partie de l'interface utilisateur du Web et, en tant que tel, il doit être totalement exempt de toute limitation technique. Nous avons perdu le "www" et pratiquement tout est un ".com". Plusieurs URL pointeront sur la même page.

Si je gagne plus d'argent avec mydomain.com/sale contre www.mondomaine.fr/produits/sale.aspx, je ne souhaite pas que des restrictions techniques me gênent.

Vous pouvez consulter un livre blanc de Roy Fielding sur le transfert d'état représentatif (REST) pour savoir quand et pourquoi . Je savais que le premier framework qui faisait la distinction entre une ressource et un fichier était Ruby on Rails - introduisant le concept d’URL vers le routage de code.

Les principaux concepts de transformation reposant sur REST étaient les suivants:

• Une URL représente une ressource
• Cette ressource peut avoir plusieurs représentations
• L'URL ne doit pas casser si l'application est restructurée
• Les applications doivent embrasser l'apatridie du Web

Le principal inconvénient de la gestion directe des fichiers par l'URL est que vous rencontrez les problèmes suivants:

• Les liens de ressources sont constamment brisés lorsque les sites Web sont réorganisés
• La ressource et la représentation sont liées

Je pense qu'il est important de fournir un juste équilibre également:

• Toutes les ressources ne sont pas d'égale importance. C'est pourquoi vous avez toujours des ressources directement liées au style (CSS, JavaScript / EcmaScript, images)
• Il existe des améliorations de REST comme HATEOAS qui prennent mieux en charge les applications à page unique.

Je ne pense pas que ce soit un artefact des frameworks d'applications Web modernes , c'est surtout un artefact de la page dynamique en général.

Dans les temps anciens , il y avait surtout des pages Web statiques, où un logiciel servi des fichiers individuels à partir du système de fichiers par leur chemin. Ils l'ont fait principalement parce que le mappage 1: 1 des chemins d'URL vers les chemins du système de fichiers (avec un répertoire désigné comme racine Web) était le choix évident, bien que la réécriture d'URL (par exemple, pour faire des redirections après le déplacement de fichiers) était également courante.

Puis vint l'âge de servir du contenu dynamique. Les scripts CGI (et tout ce qui en a résulté) ont créé les pages à la volée, reposant sur une base de données quelconque. Les paramètres GET dans l'URL sont devenus monnaie courante, par exemple en.wikipedia.org/w/index.php?title=Path_(computing) .

Cependant, il est plus convivial d’avoir une URL lisible composée uniquement de segments de chemin. Les applications dynamiques ont donc mappé des chemins simples (par exemple, en.wikipedia.org/wiki/Path_(computing) ) sur des paramètres, et ces mappages sont appelés "routes".

Peut-être que cette approche semble plus récente puisqu'elle a gagné en popularité lorsque l'importance de la convivialité a été reconnue plus largement et est également devenue une partie du référencement. C'est probablement la raison pour laquelle il a été construit directement dans les grands frameworks Web.

Une des raisons est que le chargement d'un fichier à partir du disque à chaque demande est lent. Les serveurs Web ont donc commencé à créer des moyens de mettre en cache les fichiers en mémoire. Si vous essayez néanmoins de le conserver en mémoire, pourquoi importez-vous où il se trouvait disque?

L'une des raisons est que de nombreux frameworks Web sont écrits dans des langages compilés, de sorte que vous n'avez même pas de structure de fichier sur le disque, mais simplement un jarfichier ou autre. Les langues interprétées empruntaient des idées qu’ils appréciaient aux idées compilées.

Une des raisons est le désir de plus de routes sémantiques et dynamiques, comme https://softwareengineering.stackexchange.com/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes. De toute évidence, vous ne voulez pas de /var/www/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes.phpfichier. Vous aviez l'habitude de créer des règles de réécriture d'URL dans la configuration du serveur Web pour créer des itinéraires comme celui-ci. Maintenant, il ne s'agit que d'un changement de code, ce qui est beaucoup plus simple d'un point de vue opérationnel.

L’une des principales raisons est probablement que cette approche de mappage des URI sur les chemins de fichiers a conduit à un grand nombre de publications accidentelles de données via Traversée de chemins de fichiers

Lorsque vous mappez le chemin d'accès au système de fichiers, cela signifie que vous devez ensuite vérifier que chaque chemin que vous recevez en tant que demande mappe des fichiers qui doivent être accessibles aux clients. Une approche simple pour garantir que cela ne se produise pas consiste à éliminer le mappage transparent et à le faire de manière plus explicite.

Ce n'est pas un problème uniquement lié à PHP. Comme preuve, voici une section pertinente d'un guide de durcissement Apache .

Je ne peux pas répondre pour l'industrie, mais je peux vous expliquer pourquoi j'ai abandonné l'URL = système de fichiers au début des années 2000 au profit de «routes» virtuelles.

En travaillant avec PHP 'old school', si vous avez 1 000 pages PHP, vous aurez 1 000 fichiers PHP représentant ces pages. Chaque en-tête / pied de page en double inclut et éventuellement une autre logique. Maintenant, disons que vous devez changer cela. Quel gâchis vous avez maintenant sur les mains! Vous devez soit changer tous les 1000 fichiers, soit vous vous retrouvez avec un fouillis de code très laid dans l'en-tête / les pieds de page pour gérer tous les cas. À l’aide des itinéraires virtuels, votre logique d’en-tête / pied de page, votre logique de connexion à la base de données et d’autres initialisations sont incluses une seule fois , une période. Mieux vaut travailler avec.

Une autre raison est d'éviter toute ambiguïté. À mesure que les applications se développent, les en-têtes / pieds de page inclus sont de plus en plus complexes. Ils avaient généralement des éléments inclus qui dépendaient de diverses choses. Dans le fichier PHP de la 'page', vous avez souvent rencontré une ambiguïté sur le fait de savoir si une variable isset () ou non. En utilisant des itinéraires virtuels et une application où tout ce dont vous avez besoin est chargé à chaque chargement de page, vous n'avez plus cette préoccupation.

Enfin (bien qu’il y ait d’autres raisons, mais c’est la dernière que je vais énumérer), beaucoup de ces 1 000 pages représentent du code qui serait dupliqué. Ainsi, après refactorisation dans un ensemble approprié de classes et de modèles, le code est grandement simplifié et vous pouvez faire tout ce que vous voulez faire sans avoir ces 1000 fichiers.

Je n'entrerai pas dans les détails pour expliquer pourquoi cette séparation est bénéfique. L'argument principal est que cela sépare la sémantique (à quoi voulez-vous réellement accéder) de l'implémentation sous-jacente.

Considérant que les avantages l'emportent sur les coûts - ce qui serait une question distincte -, il n'est pas difficile de voir pourquoi cela a été adopté progressivement. Je ne pense pas qu'un seul événement en soit la cause, même si je serais certainement disposé à être éduqué à ce sujet.

Au moins de mon expérience, cela se faisait au départ souvent via la configuration Apache - et vraisemblablement d’autres serveurs Web le supportaient également. Cependant, conceptuellement, il n’ya aucune bonne raison pour que le serveur soit chargé de cette tâche. Après tout, les itinéraires sont spécifiques à l’application réelle, il est donc logique de les définir ici.

Cela a changé globalement, mais comme vous l'avez fait remarquer, progressivement. La raison en est sans doute très simple: de bonnes idées réparties dans le temps. C'est aussi pourquoi ce n'est pas une surprise que le changement s'est produit globalement. Ce n'est pas que tout le monde s'est réuni et a décidé de le faire de cette façon. Au lieu de cela, chaque projet a adapté cette approche quand il pensait que ce serait bénéfique (et les projets qui ne l’appuyaient pas ont finalement disparu).

Les RFC ont déjà construit les concepts à partir de la base, avec des URI (qui n’attachaient aucune sémantique à la partie locale) et des URL en tant que cas particulier introduisant une sémantique de type chemin permettant aux documents HTML d’utiliser des liens relatifs au document. URL de base.

L’implémentation évidente consiste à mapper la partie locale de l’URL directement sur le système de fichiers. C’est donc ce qu’a fait une configuration simple: que vous utilisiez une base de données relationnelle dédiée pour rechercher un document ou tiriez parti de la clé optimisée très optimisée. -Le magasin de valeur que vous avez déjà n’importe pas à l’extérieur, mais affecte certainement votre structure de coûts pour servir les documents.

Si vous avez une application Web avec des données persistantes, cette structure de coûts change: vous devez toujours exécuter l’application et intégrer le décodage d’URL facilite la mise en œuvre de nombreuses fonctionnalités et réduit les coûts.

Au début des temps, les URL mappées directement sur les chemins de fichiers sur le serveur étaient simples à utiliser, et il n'y avait pas d'autre moyen de le faire, n'est-ce pas? Si je le demande /path/to/index.php, je /path/to/index.phpcommencerai par le répertoire racine du site Web (généralement pas par le serveur lui-même, le site Web devrait être conservé dans un répertoire ou un sous-répertoire plus bas).

Après quelques années, nous avons commencé à apprendre à réécrire, ce qui sert une ressource différente de celle qui était apparemment demandée. /request/path/to/index.phppeut réellement servir /response/path/to/index.php.

Une autre astuce se cache index.php. Si je demande pour /index.php?foo=bar&baz=quxle serveur peut répondre en se cachant index.phpcomme suit :, /?foo=bar&baz=quxtout en servant réellement de index.phptoute façon.

La prochaine étape, qui est la plus importante, consiste à rediriger toutes les URL vers /index.php. Alors maintenant, /path/to/some/pageest redirigé en silence vers /index.php?path/to/some/page. C'est un peu délicat, car chaque barre oblique représente normalement un nouveau sous-répertoire, mais dans ce cas, le serveur Web est configuré pour envoyer le chemin en tant que paramètre, au lieu de le rechercher.

Maintenant que nous avons cela, nous avons besoin d'une manière complètement différente de penser à la façon dont le site Web est organisé. Auparavant, c'était une collection lâche de pages différentes. Maintenant, tout est acheminé via une page d'entrée unique. Cela rend le site beaucoup plus compliqué, mais offre des possibilités qui n'existaient pas auparavant, telles que l'authentification d'utilisateur sur l'ensemble du site, l'application uniforme des en-têtes, des pieds de page et des styles, etc.

Il transforme efficacement votre site Web cent ou mille applications (si vous considérez chaque fichier comme étant sa propre application) en une application unique, beaucoup plus compliquée mais beaucoup plus cohérente.

C'est un énorme pas en avant, car vous ne pouvez plus dire quel code sera exécuté simplement en regardant l'URL. Vous devez maintenant avoir une compréhension approfondie de la manière dont votre infrastructure particulière traduit les chemins d'accès URL en chemins de code. Bien qu'il existe des similitudes entre les infrastructures, la plupart d'entre elles sont suffisamment différentes pour que vous ayez besoin d'une certaine familiarité pour pouvoir utiliser le code.

Bref, c’était une évolution progressive de la découverte, pas un saut soudain, et chaque développeur devait à peu près faire le même voyage de découverte. La courbe d'apprentissage est assez raide, à moins que vous ne puissiez saisir très rapidement des concepts abstraits.

En tant que webdev de longue date, je pense que l'avènement du contrôle de l'historique sans navigation ( history.pushState()) à l'époque de HTML5 a rendu cela pratique. Avant cela, vous deviez recharger la page pour mettre à jour la barre d’URL, à moins que vous ne mettiez à jour que fragment ( /path#fragment). Ce fragment étant invisible pour le serveur (il n'est pas routé), le seul moyen d'actualiser ou de marquer une page dynamique est de le faire via JavaScript.

Cela a des implications majeures pour le référencement et a amené Google à développer un schéma "hashbang" rarement utilisé qui nécessitait un mappage côté serveur des hachages dynamiques en URL physiques. Cela était lourd et non universel parmi les robots, conduisant le (faux) axiome: "les araignées ne peuvent pas explorer le contenu ajax". Mais les avantages du contenu ajax sont tangibles: essayez d’utiliser Google Maps sans JS, par exemple.

La solution était un moyen de mettre à jour la barre d’URL avec une valeur qui peut être mise en miroir sur le serveur (permettant l’actualisation des signets et l’actualisation JS-less), SANS recharger la page. Une fois que cette fonctionnalité était disponible, les développeurs pouvaient "naviguer" sur un site en mettant simplement à jour une "section de contenu principal", une barre d’URL et des chemins de navigation. Cela signifiait que tous les fichiers JS + CSS n'avaient pas besoin d'être récupérés + analysés, ce qui permettait un transfert BEAUCOUP plus rapide de page à page.