Comment et pourquoi les frameworks d'applications Web modernes ont-ils évolué pour dissocier les routes 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 URL du système de fichiers. Ceci est généralement accompli à l'aide d'un modèle de contrôleur frontal.
À savoir qu'avant, le chemin URL était mappé directement au système de fichiers et reflétait donc les fichiers et dossiers exacts sur le disque, de nos jours, les chemins 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 des fichiers.
Question
Comment et pourquoi cela est-il devenu monnaie courante? Comment et pourquoi a-t-il été décidé que c'était "mieux" au point où l'approche autrefois banale du dépôt direct était effectivement abandonnée?
Autres réponses
Il y a une réponse similaire ici qui va un peu dans le concept de route et certains avantages et inconvénients: Avec PHP frameworks, pourquoi le concept de "route" est-il utilisé ?
Mais il ne traite pas des aspects des changements historiques, ni comment ni pourquoi ce changement s'est progressivement produit, à l'endroit où de nouveaux projets utilisent aujourd'hui à peu près ce nouveau modèle de style de routage et le direct vers le fichier est obsolète ou abandonné.
De plus, la plupart de ces avantages et inconvénients mentionnés ne semblent pas suffisamment importants pour justifier un tel changement global. Le seul avantage que je peux voir conduire ce changement est peut-être de cacher le système de fichiers/dossiers à l'utilisateur final, et aussi le manque de ?param=value¶m2=value, ce qui rend les URL un peu plus propres. Mais étaient-ce la seule raison du changement? Et si oui, pourquoi y avait-il ceux-là raisons?
Exemples:
Je connais très bien PHP et de nombreux frameworks modernes populaires utilisent cette approche de routage découplé. Pour que cela fonctionne, vous configurez réécriture d'URL dans Apache ou un serveur Web similaire, à l'endroit où la fonctionnalité d'application Web n'est généralement plus déclenchée via un chemin URL direct vers le 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/Cadre Zend
https://docs.zendframework.com/zend-mvc/routing/
Laravel
https://laravel.com/docs/5.5/routing
CakePHP
Dans sa forme la plus élémentaire, un site Web sert des fichiers statiques. Le mappage du chemin URL vers un chemin de fichier est le choix le plus évident; il s'agit essentiellement d'un site FTP en lecture seule.
Ensuite, les gens ont voulu changer le contenu de la page avec des scripts. Le moyen le plus simple consiste à intégrer un langage de script dans la page et à l'exécuter via un interpréteur. Encore une fois, étant donné le chemin déjà existant -> le routage du chemin du fichier, c'était assez simple.
Mais vraiment, vous exécutez ce fichier comme argument pour l'interpréteur maintenant. 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 langues compilées plus avancées, vous êtes encore plus séparé de l'emplacement du fichier.
De plus, votre serveur Web met déjà en cache des fichiers statiques et fait 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 d'accès au système de fichiers de liens est plus un obstacle qu'une aide.
Mais je pense que le véritable changement est survenu lorsque les utilisateurs ont voulu se débarrasser de l'extension de fichier du chemin. Obtenir myPage.asp ou myPage.php était quelque chose qui déroutait les gens "normaux" et interférait avec le référencement.
Étant donné que l'utilisateur voit le chemin, il est devenu partie intégrante de l'interface utilisateur du Web et, en tant que tel, il doit être complètement libre de toute limitation technique. Nous avons perdu le "www" et pratiquement tout est un ".com". Plusieurs URL pointeront vers la même page.
Si je gagne plus d'argent avec mydomain.com/sale vs www.mydomain.co.uk/products/sale.aspx, alors je ne veux pas que des limitations techniques me gênent.
Vous pouvez consulter un livre blanc de Roy Fielding sur REpresentational State Transfer (REST) quant au lorsque et le pourquoi . Le premier framework que je connaissais qui faisait la distinction entre une ressource et un fichier était Ruby on Rails - introduisant le concept de l'URL au routage de code.
Les principaux concepts derrière REST qui étaient transformationnels étaient:
- Une URL représente une ressource
- Cette ressource peut avoir plusieurs représentations
- L'URL ne doit pas se casser si l'application est restructurée
- Les applications doivent englober l'apatridie du Web
Le principal inconvénient de la diffusion directe des fichiers par l'URL est que vous rencontrez les problèmes suivants:
- Les liens vers les ressources sont constamment rompus à mesure que les sites Web sont réorganisés
- La ressource et la représentation sont liées
Je pense qu'il est également important d'assurer un juste équilibre:
- Toutes les ressources n'ont pas la même importance. C'est pourquoi vous avez toujours des ressources basées sur le style servies directement (CSS, JavaScript/EcmaScript, images)
- Il existe des améliorations de REST comme HATEOAS qui prennent mieux en charge les applications d'une seule page.
Je ne pense pas que ce soit un artefact de frameworks d'applications web modernes , c'est surtout un artefact de page dynamique servant en général.
Autrefois , il y avait surtout des pages Web statiques, où un logiciel servait des fichiers individuels du système de fichiers par leur chemin. Ils l'ont fait principalement parce que le mappage 1: 1 des chemins 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 effectuer des redirections après le déplacement de fichiers) soit également courante.
Puis vint l'ère de la diffusion de contenu dynamique. Les scripts CGI (et tout ont évolué à partir d'eux) ont créé les pages à la volée, étant soutenus par 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) ) à des paramètres, et ces mappages sont connus sous le nom de "routes".
Peut-être que cette approche semble plus récente car elle a gagné en popularité lorsque l'importance de l'utilisabilité a été reconnue plus largement et a également fait partie du référencement. C'est probablement la raison pour laquelle il a été intégré directement dans les grands frameworks Web.
L'une des raisons est que le chargement d'un fichier à partir du disque à chaque demande est lent, donc les serveurs Web ont commencé à créer des moyens de mettre en cache les fichiers en mémoire, alors si vous essayez de le garder en mémoire de toute façon, pourquoi est-il important de savoir où il se trouvait disque?
L'une des raisons est que de nombreux frameworks Web sont écrits dans des langages compilés, vous n'avez donc même pas de structure de fichier sur le disque, juste un fichier jar ou autre. Les langues interprétées ont emprunté les idées qu'elles aimaient aux compilées.
L'une des raisons est le désir d'itinéraires plus sémantiques et dynamiques, comme https://softwareengineering.stackexchange.com/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes. Évidemment, vous ne voulez pas de /var/www/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes.php fichier. Vous avez utilisé pour 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, c'est juste un changement de code, ce qui est beaucoup plus simple sur le plan opérationnel.
L'une des principales raisons est probablement que cette approche de mappage des URI aux chemins de fichiers a conduit à un grand nombre de diffusions accidentelles de données via File Path Traversal
Lorsque vous mappez le chemin d'accès au système de fichiers, cela signifie que vous devez ensuite vérifier que chaque chemin d'accès que vous recevez en tant que demande correspond aux fichiers qui doivent être accessibles aux clients. Une approche simple pour garantir que cela ne se produit pas consiste à éliminer la cartographie transparente et à le faire de manière plus explicite.
Ce n'est pas un problème uniquement 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 dire pourquoi je me suis éloigné du système de fichiers URL = au début des années 2000 vers des "routes" virtuelles.
Travailler avec PHP "old school", si vous avez 1000 PHP, vous auriez 1000 PHP représentant ces pages. Chacun en-tête/Le pied de page inclut et peut-être une autre logique. Maintenant, disons que vous devez changer cela./footers pour gérer tous les cas. En utilisant des routes virtuelles, votre logique d'en-tête/pied de page, la logique de connexion à la base de données et d'autres initialisations sont incluses ne fois, point. Il vaut bien mieux 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 qui sont inclus deviennent plus complexes. Ils avaient généralement des inclusions imbriquées qui dépendaient de diverses choses. Dans le fichier PHP pour la "page", vous avez souvent rencontré une ambiguïté quant à savoir si une variable isset () ou non. Utilisation de routes virtuelles, et une application où tout ce dont vous avez besoin est chargé à chaque chargement de page , vous n'avez plus ce souci.
Enfin (bien qu'il y ait d'autres raisons, mais c'est la dernière que je vais énumérer), beaucoup de ces 1000 pages représentent du code qui serait dupliqué. Ainsi, après refactoring dans un ensemble approprié de classes et de modèles, le code est considérablement simplifié et vous pouvez faire tout ce que vous voulez sans avoir ces 1000 fichiers.
Je n'entrerai pas trop dans les détails pour expliquer pourquoi cette séparation est bénéfique. L'argument principal est qu'il sépare la sémantique (à quoi essayez-vous réellement d'accéder) de l'implémentation sous-jacente.
Étant donné que les avantages l'emportent sur les coûts en tant que tels - ce qui serait une question distincte - il n'est pas difficile de voir pourquoi il a été progressivement adopté. Je ne pense pas qu'il y ait un seul événement qui a causé cela, même si je serais certainement ouvert à être éduqué à ce sujet.
Au moins d'après mon expérience, au départ, cela se faisait souvent via la configuration Apache - et probablement d'autres serveurs Web le supportaient également. Cependant, conceptuellement, il n'y a aucune bonne raison pour laquelle le serveur devrait être chargé de cela. Après tout, les itinéraires sont spécifiques à l'application réelle, il est donc logique de les définir là-bas.
Cela a changé à l'échelle mondiale, mais comme vous le faites remarquer, progressivement. La raison en est certainement très simple: les bonnes idées se propagent dans le temps. C'est aussi pourquoi ce n'est pas une telle surprise que le changement s'est produit à l'échelle mondiale. Ce n'est pas que tout le monde se soit réuni et ait décidé de le faire de cette façon. Au contraire, chaque projet a adapté cette approche quand il a pensé qu'elle serait bénéfique (et les projets qui ne l'ont pas soutenu ont finalement disparu).
Les RFC ont déjà construit les concepts à partir de zéro, avec des URI (qui n'ont attaché aucune sémantique à la partie locale) et des URL comme cas spécial qui a introduit une sémantique de type chemin pour permettre 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 que les configurations simples ont fait - que vous utilisiez une base de données relationnelle dédiée pour rechercher un document, ou que vous profitiez de la clé à faible surcharge très optimisée -le magasin de valeurs que vous avez déjà n'a pas d'importance à l'extérieur, mais affecte certainement votre structure de coûts pour la signification des documents.
Si vous avez une application Web avec des données persistantes, cette structure de coûts change: vous avez toujours la charge de l'exécution de l'application, et l'intégration du décodage d'URL dans celle-ci facilite la mise en œuvre de nombreuses fonctionnalités, réduisant les coûts.
Au début, les URL sont directement mappées aux chemins de fichiers sur le serveur parce que c'est facile, et il n'y a pas d'autre moyen de le faire de toute façon, n'est-ce pas? Si je demande /path/to/index.php, J'aurais /path/to/index.php à partir du répertoire racine du site Web (généralement pas du serveur lui-même, le site Web doit être conservé dans un répertoire ou un sous-répertoire plus bas).
Puis, après quelques années, nous avons commencé à apprendre la réécriture, qui sert une ressource différente de celle qui était apparemment demandée. /request/path/to/index.php peut effectivement servir /response/path/to/index.php.
Une autre astuce consiste à cacher index.php. Si je demande /index.php?foo=bar&baz=qux le serveur peut répondre en masquant index.php ainsi: /?foo=bar&baz=qux, tout en servant réellement index.php en tous cas.
L'étape suivante, qui est la plus importante, est que nous avons appris à rediriger les URL all vers /index.php. Alors maintenant, /path/to/some/page est redirigé en silence vers /index.php?path/to/some/page. C'est un peu délicat, car normalement chaque barre oblique représente un nouveau sous-répertoire, mais dans ce cas, le serveur Web est configuré pour envoyer le chemin d'accès en tant que paramètre, au lieu de le regarder.
Maintenant que nous avons cela, nous avons besoin d'une façon complètement différente de penser à la façon dont le site Web est organisé. Avant, c'était une collection lâche de différentes pages. Maintenant, tout est acheminé via une seule page d'entrée. Cela rend le site beaucoup plus compliqué, mais offre des opportunités qui n'étaient pas disponibles auparavant, telles que l'authentification des utilisateurs à l'échelle du site, l'application uniforme des en-têtes, pieds de page et styles, etc.
Il transforme efficacement votre site Web cent ou mille applications (si vous considérez chaque fichier comme sa propre application) en une application unique, beaucoup plus compliquée mais beaucoup plus cohérente.
C'est un énorme bond, 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 façon dont votre cadre particulier traduit les chemins d'URL en chemins de code, et bien qu'il existe des similitudes entre les cadres, la plupart sont suffisamment différents pour que vous ayez besoin d'une certaine familiarité pour pouvoir travailler avec le code.
Pour faire court, ce fut une évolution progressive de la découverte, pas un saut soudain, et chaque développeur devait à peu près suivre le même parcours de découverte. La courbe d'apprentissage est assez abrupte, à moins que vous ne puissiez saisir les concepts abstraits très rapidement.