Wie und warum haben sich moderne Webanwendungs-Frameworks entwickelt, um URL-Routen vom Dateisystem zu entkoppeln?

Im Vergleich zu vor ungefähr 10 Jahren habe ich eine Verschiebung hin zu Frameworks festgestellt, die den Routing-Stil verwenden und den URL-Pfad vom Dateisystem entkoppeln. Dies wird normalerweise mithilfe eines Front-Controller-Musters durchgeführt.

Früher wurde der URL-Pfad direkt dem Dateisystem zugeordnet und spiegelte daher die exakten Dateien und Ordner auf der Festplatte wider. Heutzutage sind die tatsächlichen URL-Pfade so programmiert, dass sie über die Konfiguration an bestimmte Klassen weitergeleitet werden und als solche die Datei nicht mehr widerspiegeln Systemordner und Dateistruktur.

Frage

Wie und warum wurde das alltäglich? Wie und warum wurde entschieden, dass es "besser" ist bis zu dem Punkt, an dem der früher übliche Direct-to-File-Ansatz effektiv aufgegeben wurde?

Andere Antwort

Es gibt hier eine ähnliche Antwort, die sich ein wenig mit dem Konzept der Route und einigen Vor- und Nachteilen befasst: Warum wird bei PHP-Frameworks das "Route" -Konzept verwendet?

Es geht jedoch nicht auf historische Änderungsaspekte ein, oder darauf, wie oder warum diese Änderung allmählich stattfand, bei denen heutzutage neue Projekte so gut wie dieses neue Routingstilmuster verwenden und Direct-to-File veraltet ist oder aufgegeben wird.

Außerdem scheinen die meisten der genannten Vor- und Nachteile nicht bedeutend genug zu sein, um eine solche globale Änderung zu rechtfertigen. Der einzige Vorteil, den ich sehen kann, ist, dass ich das Datei- / Ordnersystem vor dem Endbenutzer verstecke und auch, dass es keinen gibt ?param=value&param2=value, wodurch URLs ein bisschen sauberer aussehen. Aber waren das die einzigen Gründe für die Veränderung? Und wenn ja, warum steckten diese Gründe dahinter?

Beispiele:

Ich bin am besten mit PHP-Frameworks vertraut, und viele beliebte moderne Frameworks verwenden diesen entkoppelten Routing-Ansatz. Damit dies funktioniert, richten Sie die URL-Umschreibung in Apache oder einem ähnlichen Webserver ein, auf dem die Webanwendungsfunktionalität normalerweise nicht mehr über einen URL-Pfad direkt zur Datei ausgelöst wird.

Zend Expressive

https://docs.zendframework.com/zend-expressive/features/router/aura/
https://docs.zendframework.com/zend-expressive/features/router/fast-route/
https: //docs.zendframework. de / 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/de/development/routing.html

In der einfachsten Form stellt eine Website statische Dateien bereit. Das Zuordnen des URL-Pfads zu einem Dateipfad ist die naheliegendste Wahl. Im Wesentlichen handelt es sich um eine schreibgeschützte FTP-Site.

Dann wollten die Leute den Inhalt der Seite mit einigen Skripten ändern. Am einfachsten ist es, eine Skriptsprache in die Seite einzubetten und über einen Interpreter auszuführen. Auch dies war angesichts der bereits vorhandenen Pfad-> Dateipfad-Weiterleitung einfach genug.

Aber in Wirklichkeit führen Sie diese Datei jetzt als Argument für den Interpreter aus. Sie müssen angeben, wann die Anforderung eine statische Datei und wann eine zu interpretierende Datei ist.

Sobald Sie mit der Verwendung erweiterter kompilierter Sprachen beginnen, sind Sie vom Speicherort der Dateien noch weiter entfernt.

Außerdem speichert Ihr Webserver bereits statische Dateien im Cache und führt alle möglichen Optimierungen durch. Dies bedeutet, dass das Dateisystem eher die Ausnahme als die Regel darstellt. Zu diesem Zeitpunkt ist der alte Linkdateisystempfad eher ein Hindernis als eine Hilfe.

Aber ich denke, die wirkliche Veränderung kam, als die Benutzer die Dateierweiterung aus dem Pfad entfernen wollten. MyPage.asp oder myPage.php zu bekommen war etwas, das "normale" Leute verwirrte und SEO störte.

Da der Benutzer den Pfad sieht, ist er Teil der Benutzeroberfläche des Webs geworden und muss daher völlig frei von technischen Einschränkungen sein. Wir haben das "www" verloren und praktisch alles ist ein ".com". Mehrere URLs verweisen auf dieselbe Seite.

Wenn ich mit mydomain.com/sale im Vergleich zu www.mydomain.co.uk/products/sale.aspx mehr Geld verdiene, möchte ich nicht, dass mir technische Einschränkungen im Weg stehen.

In einem Whitepaper von Roy Fielding zu REpresentational State Transfer (REST) ​​erfahren Sie , wann und warum . Das erste Framework, von dem ich wusste, dass es zwischen einer Ressource und einer Datei unterschied, war Ruby on Rails - eine Einführung in das Konzept der URL für das Code-Routing.

Die wichtigsten Konzepte hinter REST, die transformativ waren, waren:

• Eine URL repräsentiert eine Ressource
• Diese Ressource kann mehrere Darstellungen haben
• Die URL sollte nicht beschädigt werden, wenn die Anwendung umstrukturiert wird
• Anwendungen sollten die Staatenlosigkeit des Webs berücksichtigen

Der Hauptnachteil der direkten Bereitstellung von Dateien über die URL besteht darin, dass die folgenden Probleme auftreten:

• Ressourcen-Links werden ständig unterbrochen, wenn Websites neu organisiert werden
• Ressource und Repräsentation sind miteinander verbunden

Ich denke, es ist wichtig, auch für ein faires Gleichgewicht zu sorgen:

• Nicht alle Ressourcen sind gleich wichtig. Aus diesem Grund werden Ihnen immer noch stilbasierte Ressourcen direkt zur Verfügung gestellt (CSS, JavaScript / EcmaScript, Bilder).
• Es gibt Verbesserungen von REST wie HATEOAS , die Apps für einzelne Seiten besser unterstützen.

Ich denke nicht, dass es sich um ein Artefakt moderner Webanwendungs-Frameworks handelt, sondern hauptsächlich um ein Artefakt dynamischer Seiten, die im Allgemeinen bereitgestellt werden.

In den alten Tagen gab es meist statische Web - Seiten, auf denen eine Software einzelne Dateien aus dem Dateisystem von ihrem Weg serviert. Dies geschah hauptsächlich deshalb, weil die 1: 1-Zuordnung von URL-Pfaden zu Dateisystempfaden (mit einem Verzeichnis als Webstamm) naheliegend war, obwohl auch das Umschreiben von URLs (z. B. zum Umleiten nach dem Verschieben von Dateien) häufig vorkam.

Dann kam das Zeitalter der Bereitstellung dynamischer Inhalte. CGI-Skripte (und alles, was daraus entstanden ist) erstellten die Seiten im laufenden Betrieb und wurden von einer Datenbank gesichert. GET-Parameter in URLs waren an der Tagesordnung, zum Beispiel en.wikipedia.org/w/index.php?title=Path_(computing) .

Es ist jedoch benutzerfreundlicher , eine lesbare URL zu haben, die nur aus Pfadsegmenten besteht. Die dynamischen Anwendungen haben also einfache Pfade (z. B. en.wikipedia.org/wiki/Path_(computing) auf Parameter abgebildet , und diese Zuordnungen werden als "Routen" bezeichnet.

Vielleicht fühlt sich dieser Ansatz jünger an, da er an Popularität gewann, als die Wichtigkeit der Benutzerfreundlichkeit allgemein anerkannt wurde und auch Teil von SEO wurde. Dies ist wahrscheinlich der Grund, warum es direkt in die großen Web-Frameworks eingebaut wurde.

Ein Grund dafür ist, dass das Laden einer Datei von der Festplatte bei jeder Anforderung langsam ist. Daher haben Webserver damit begonnen, Methoden zum Zwischenspeichern von Dateien im Speicher zu erstellen. Wenn Sie dann trotzdem versuchen, die Datei im Speicher zu behalten, warum spielt es dann eine Rolle, wo sie sich befand? Platte?

Ein Grund dafür ist, dass viele Webframeworks in kompilierten Sprachen geschrieben sind, sodass Sie nicht einmal eine Dateistruktur auf der Festplatte haben, sondern nur eine jarDatei oder was auch immer. Ausgedeutete Sprachen liehen Ideen aus, die sie von den kompilierten mochten.

Ein Grund ist der Wunsch nach semantischeren, dynamischeren Routen https://softwareengineering.stackexchange.com/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes. Offensichtlich möchten Sie keine /var/www/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes.phpDatei. Sie haben in der Webserverkonfiguration Regeln zum Umschreiben von URLs festgelegt, um Routen wie diese zu erstellen. Jetzt ist es nur eine Codeänderung, die im Betrieb viel einfacher ist.

Einer der Hauptgründe ist wahrscheinlich, dass dieser Ansatz des Zuordnens von URIs zu Dateipfaden zu einer großen Anzahl versehentlicher Datenfreigaben über File Path Traversal geführt hat

Wenn Sie den Pfad dem Dateisystem zuordnen, müssen Sie dann überprüfen, ob jeder Pfad, den Sie als Anforderung erhalten, Dateien zugeordnet ist, auf die Clients zugreifen können sollen. Ein einfacher Ansatz, um zu gewährleisten, dass dies nicht der Fall ist, besteht darin, die transparente Zuordnung zu beseitigen und sie expliziter auszuführen.

Dies ist kein reines PHP-Problem. Als Beweis dient hier ein relevanter Abschnitt eines Apache-Härtungsleitfadens .

Ich kann für die Branche keine Antwort geben, aber ich kann Ihnen sagen, warum ich in den frühen 2000er Jahren vom URL = Dateisystem weggegangen bin und mich virtuellen "Routen" zugewandt habe.

Wenn Sie mit 'old school' PHP arbeiten und über 1000 PHP-Seiten verfügen, verfügen Sie über 1000 PHP-Dateien, die diese Seiten darstellen. Jede duplizierende Kopf- / Fußzeile enthält und möglicherweise eine andere Logik. Nehmen wir an, Sie müssen das ändern. Was für ein Durcheinander hast du jetzt in deinen Händen! Entweder müssen Sie alle 1000 Dateien ändern, oder Sie erhalten ein Durcheinander von sehr hässlichem Code in den Kopf- / Fußzeilen, um alle Fälle zu behandeln. Bei Verwendung virtueller Routen werden die Kopf- / Fußzeilenlogik, die Datenbankverbindungslogik und andere Initialisierungen einmal pro Periode berücksichtigt . Viel besser zum Arbeiten.

Ein weiterer Grund ist die Vermeidung von Mehrdeutigkeiten. Mit zunehmender Anzahl von Anwendungen werden die enthaltenen Kopf- und Fußzeilen komplexer. Sie hatten normalerweise eigene verschachtelte Gruppen, die von verschiedenen Dingen abhingen. In der PHP-Datei für die 'Seite' gab es häufig Unklarheiten darüber, ob eine Variable isset () ist oder nicht. Wenn Sie virtuelle Routen verwenden und eine Anwendung verwenden, in der bei jedem Seitenladevorgang alles geladen wird, was Sie benötigen, besteht dieses Problem nicht mehr.

Schließlich (obwohl es andere Gründe gibt, aber es ist die letzte, die ich auflisten werde), repräsentieren viele dieser 1000 Seiten Code, der dupliziert werden würde. Nach dem Refactoring in einen geeigneten Satz von Klassen und Vorlagen wird der Code stark vereinfacht und Sie können alles tun, was Sie wollen, ohne diese 1000 Dateien zu haben.

Ich werde nicht zu sehr ins Detail gehen, warum diese Trennung vorteilhaft ist. Das Hauptargument ist, dass es die Semantik (auf die Sie tatsächlich zugreifen möchten) von der zugrunde liegenden Implementierung trennt.

Wenn man davon ausgeht, dass die Vorteile die Kosten überwiegen - was eine separate Frage wäre -, ist es nicht schwer zu erkennen, warum sie schrittweise übernommen wurden. Ich glaube nicht, dass es ein einziges Ereignis gibt, das dies verursacht hat, obwohl ich auf jeden Fall offen dafür wäre, darüber informiert zu werden.

Zumindest nach meiner Erfahrung wurde dies anfangs häufig über die Apache-Konfiguration durchgeführt - und vermutlich auch von anderen Webservern unterstützt. Konzeptionell gibt es jedoch keinen guten Grund, warum der Server damit beauftragt werden sollte. Die Routen sind schließlich anwendungsspezifisch, daher ist es sinnvoll, sie dort zu definieren.

Dies hat sich global geändert, aber wie Sie bereits betont haben, schrittweise. Der Grund dafür ist mit ziemlicher Sicherheit sehr einfach: Gute Ideen, die sich über die Zeit ausbreiten. Aus diesem Grund ist es auch nicht verwunderlich, dass der Wandel global stattgefunden hat. Es ist nicht so, dass alle zusammengekommen sind und beschlossen haben, es auf diese Weise zu tun. Vielmehr passte jedes Projekt diesen Ansatz an, als sie es für nützlich hielten (und Projekte, die ihn nicht unterstützten, verschwanden schließlich).

Die RFCs haben die Konzepte bereits von Grund auf mit URIs (die dem lokalen Teil keine Semantik hinzufügten) und URLs als Sonderfall erstellt, die pfadähnliche Semantik einführten, damit HTML-Dokumente Links relativ zum Dokument verwenden können Basis-URL.

Die naheliegende Implementierung besteht darin, den lokalen Teil der URL direkt dem Dateisystem zuzuordnen. Dies war also bei einfachen Setups der Fall - unabhängig davon, ob Sie eine dedizierte relationale Datenbank zum Nachschlagen eines Dokuments verwenden oder den hochoptimierten Low-Overhead-Schlüssel nutzen -Wertspeicher, den Sie bereits haben, spielt für die Außenwelt keine Rolle, wirkt sich jedoch auf Ihre Kostenstruktur für die Zustellung der Dokumente aus.

Wenn Sie eine Webanwendung mit persistenten Daten haben, ändert sich diese Kostenstruktur: Sie haben immer den Overhead, die Anwendung auszuführen, und die Integration der URL-Dekodierung erleichtert die Implementierung vieler Funktionen und senkt die Kosten.

Zu Beginn wurden URLs direkt Dateipfaden auf dem Server zugeordnet, da dies einfach ist und es sowieso keine andere Möglichkeit gibt, oder? Wenn ich danach frage /path/to/index.php, gehe ich /path/to/index.phpvom Stammverzeichnis der Website aus (normalerweise nicht vom Server selbst, die Website sollte sich in einem Verzeichnis oder einem Unterverzeichnis weiter unten befinden).

Dann, nach ein paar Jahren, lernten wir über das Umschreiben, das eine andere Ressource bedient als die, nach der anscheinend gefragt wurde. /request/path/to/index.phpkann eigentlich dienen /response/path/to/index.php.

Ein weiterer Trick ist das Verstecken index.php. Wenn ich nach /index.php?foo=bar&baz=quxdem Server frage, kann man sich index.phpwie folgt verstecken :, die /?foo=bar&baz=quxganze Zeit eigentlich index.phptrotzdem bedienen .

Der nächste wichtige Schritt ist, dass wir gelernt haben, alle URLs umzuleiten /index.php. Also jetzt /path/to/some/pagewird stillschweigend weitergeleitet /index.php?path/to/some/page. Dies ist etwas knifflig, da normalerweise jeder Schrägstrich ein neues Unterverzeichnis darstellt. In diesem Fall ist der Webserver jedoch so konfiguriert, dass der Pfad als Parameter gesendet wird, anstatt darin nachzuschauen.

Jetzt, da wir das haben, brauchen wir eine völlig andere Art zu überlegen, wie die Website organisiert ist. Vorher war es eine lose Sammlung verschiedener Seiten. Jetzt wird alles über eine einzige Eingabeseite geleitet. Dies macht die Site viel komplizierter, bietet jedoch Möglichkeiten, die zuvor nicht zur Verfügung standen, z. B. die standortweite Benutzerauthentifizierung, die einheitliche Anwendung von Kopf- und Fußzeilen sowie Formatvorlagen usw.

Es verwandelt Ihre Hundert- oder Tausend-App-Website (wenn Sie jede Datei als eigene App betrachten) in eine einzige, viel kompliziertere, aber viel konsistentere App.

Dies ist ein enormer Sprung, da Sie anhand der URL nicht mehr erkennen können, welcher Code ausgeführt wird. Sie müssen jetzt genau wissen, wie Ihr spezielles Framework URL-Pfade in Codepfade übersetzt, und obwohl es Ähnlichkeiten zwischen Frameworks gibt, sind die meisten so unterschiedlich, dass Sie eine gewisse Vertrautheit benötigen, um mit dem Code arbeiten zu können.

Kurz gesagt, es war eine schrittweise Entwicklung der Entdeckung, kein plötzlicher Sprung, und jeder Entwickler musste so ziemlich dieselbe Entdeckungsreise durchlaufen. Die Lernkurve ist ziemlich steil, es sei denn, Sie können abstrakte Konzepte sehr schnell erfassen.

Als langjähriger Webdev habe ich das Aufkommen der navigationslosen Verlaufskontrolle ( history.pushState()) um die Zeit von HTML5 für praktisch befunden . Vorher mussten Sie die Seite neu laden, um die URL-Leiste zu aktualisieren, es sei denn, Sie haben nur das Fragment ( /path#fragment) aktualisiert . Dieses Fragment war für den Server unsichtbar (es wird nicht weitergeleitet). Die einzige Möglichkeit, eine dynamische Seite zu aktualisieren oder mit einem Lesezeichen zu versehen, war JavaScript.

Dies hat erhebliche Auswirkungen auf SEO und veranlasst Google, ein selten verwendetes "Hashbang" -Schema zu entwickeln , das eine serverseitige Zuordnung von dynamischen Hashes zu physischen URLs erfordert. Dies war unhandlich und unter Robotern nicht universell und führte das (falsche) Axiom an: "Spinnen können keine Ajax-Inhalte crawlen". Die Vorteile von Ajax-Inhalten sind jedoch greifbar: Verwenden Sie beispielsweise Google Maps ohne JS.

Die Lösung war eine Möglichkeit, die URL-Leiste mit einem Wert zu aktualisieren, der auf dem Server gespiegelt werden kann (Lesezeichen und JS-freie Aktualisierung möglich), OHNE die Seite erneut zu laden. Sobald diese Funktion verfügbar war, konnten Entwickler auf einer Site "navigieren", indem sie einfach einen "Hauptinhaltsabschnitt", eine URL-Leiste und Brotkrumen aktualisierten. Dies bedeutete, dass alle JS + CSS nicht erneut abgerufen und analysiert werden mussten, was eine VIEL schnellere Übertragung von Seite zu Seite ermöglichte.