it-swarm.com.de

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, der den URL-Pfad vom Dateisystem entkoppelt. Dies wird typischerweise mit Hilfe eines Front-Controller-Musters erreicht.

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

Frage

Wie und warum wurde dies alltäglich? Wie und warum wurde entschieden, dass es "besser" ist, bis der einst übliche Direct-to-File-Ansatz effektiv aufgegeben wurde?

Andere Antworten

Hier gibt es eine ähnliche Antwort, die sich ein wenig mit dem Konzept der Route und einigen Vor- und Nachteilen befasst: Mit PHP Frameworks, warum wird das Konzept "Route" verwendet? ?

Es geht jedoch nicht auf historische Änderungsaspekte ein oder darauf, wie oder warum diese Änderung allmählich erfolgte, wenn neue Projekte heutzutage dieses neue Routing-Stilmuster verwenden und Direct-to-File veraltet oder aufgegeben wird.

Außerdem scheinen die meisten der genannten Vor- und Nachteile nicht signifikant genug zu sein, um eine solche globale Veränderung zu rechtfertigen. Der einzige Vorteil, den ich möglicherweise bei dieser Änderung sehen kann, ist das Ausblenden des Datei-/Ordnersystems vor dem Endbenutzer und auch das Fehlen von ?param=value&param2=value, wodurch URLs ein bisschen sauberer aussehen. Aber waren das der einzige Grund für die Änderung? Und wenn ja, warum waren diese Gründe dahinter?

Beispiele:

Ich bin am besten vertraut mit PHP Frameworks und viele gängige moderne Frameworks verwenden diesen entkoppelten Routing-Ansatz. Damit dies funktioniert, richten Sie RL-Umschreiben in Apache oder einem ähnlichen Webserver ein. Wo Webanwendungsfunktionen normalerweise nicht mehr über einen URL-Pfad direkt zur Datei ausgelöst werden.

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

66
Dennis

In ihrer einfachsten Form liefert eine Website statische Dateien. 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 des bereits vorhandenen Pfads -> Dateipfadroutings einfach genug.

Aber wirklich, Sie führen diese Datei jetzt als Argument für den Interpreter aus. Sie müssen identifizieren, wann die Anforderung eine statische Datei ist und wann es sich um etwas handelt, das Sie interpretieren müssen.

Sobald Sie fortgeschrittenere kompilierte Sprachen verwenden, sind Sie noch mehr vom Speicherort der Datei getrennt.

Außerdem speichert Ihr Webserver bereits statische Dateien zwischen und führt alle Arten von Optimierungen durch. Dies bedeutet, dass das Aufrufen des Dateisystems eher die Ausnahme als die Regel ist. Zu diesem Zeitpunkt ist der alte Pfad des Link-Dateisystems eher ein Hindernis als eine Hilfe.

Aber ich denke, die wirkliche grundlegende Veränderung kam, als Benutzer die Dateierweiterung vom Pfad entfernen wollten. Das Abrufen von myPage.asp oder myPage.php war etwas, das "normale" Leute verwirrte und die Suchmaschinenoptimierung 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 vs www.mydomain.co.uk/products/sale.aspx mehr Geld verdiene, möchte ich nicht, dass mir technische Einschränkungen im Weg stehen.

71
Ewan

Sie können sich ein Whitepaper von Roy Fielding über REpresentational State Transfer (REST) zum wann und zum warum ansehen. Das erste Framework, das mir bewusst war, dass zwischen einer Ressource und einer Datei unterschieden wurde, war Ruby on Rails - Einführung des Konzepts der URL für das Code-Routing.

Die Hauptkonzepte hinter REST, die transformierend waren) waren:

  • Eine URL repräsentiert eine Ressource
  • Diese Ressource kann mehrere Darstellungen haben
  • Die URL sollte nicht unterbrochen 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 folgende Probleme auftreten:

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

Ich denke, es ist wichtig, auch ein faires Gleichgewicht zu schaffen:

  • Nicht alle Ressourcen sind gleich wichtig. Aus diesem Grund werden immer noch stilbasierte Ressourcen direkt bereitgestellt (CSS, JavaScript/EcmaScript, Bilder).
  • Es gibt Verbesserungen von REST like HASSOAS , die Apps für einzelne Seiten besser unterstützen.
38
Berin Loritsch

Ich denke nicht, dass es ein Artefakt von modernen Webanwendungs-Frameworks ist, es ist meistens ein Artefakt von dynamischen Seiten, die im Allgemeinen dienen.

In den alten Zeiten gab es meist statische Webseiten, auf denen eine Software einzelne Dateien aus dem Dateisystem über ihren Pfad bereitstellte. Sie taten dies hauptsächlich, weil die 1: 1-Zuordnung von URL-Pfaden zu Dateisystempfaden (wobei ein Verzeichnis als Webstamm bezeichnet wurde) die offensichtliche Wahl war, obwohl das Umschreiben von URLs (z. B. um Weiterleitungen nach dem Verschieben von Dateien vorzunehmen) ebenfalls üblich war.

Dann kam das Zeitalter, in dem dynamische Inhalte bereitgestellt wurden. CGI-Skripte (und alles, was daraus entstanden ist) haben die Seiten im laufenden Betrieb erstellt und von einer Datenbank unterstützt. GET-Parameter in URL wurden zum Beispiel alltäglich, 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. Daher haben die dynamischen Anwendungen einfache Pfade (z. B. en.wikipedia.org/wiki/Path_(computing) ) Parametern zugeordnet, und diese Zuordnungen werden als "Routen" bezeichnet.

Vielleicht fühlt sich dieser Ansatz jünger an, als er an Popularität gewann, als die Bedeutung 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 integriert wurde.

20
Bergi

Ein Grund dafür ist, dass das Laden einer Datei von der Festplatte bei jeder Anforderung langsam ist. Daher haben Webserver damit begonnen, Möglichkeiten zum Zwischenspeichern von Dateien im Speicher zu erstellen. Wenn Sie dann versuchen, sie trotzdem im Speicher zu halten, 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 jar -Datei oder was auch immer. Interpretierte Sprachen liehen sich Ideen aus, die sie von den kompilierten mochten.

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

12
Karl Bielefeldt

Einer der Hauptgründe ist wahrscheinlich, dass dieser Ansatz der Zuordnung 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, bedeutet dies, dass Sie überprüfen müssen, ob jeder Pfad, den Sie als Anforderung erhalten, Dateien zugeordnet ist, auf die Clients zugreifen können sollen. Ein einfacher Ansatz, um sicherzustellen, dass dies nicht geschieht, besteht darin, die transparente Zuordnung zu eliminieren und expliziter durchzuführen.

Dies ist kein reines PHP-Problem. Als Beweis dient hier ein relevanter Abschnitt eines Apache Hardening Guide .

11
JimmyJames

Ich kann nicht für die Branche antworten, aber ich kann Ihnen sagen, warum ich mich Anfang der 2000er Jahre vom URL = Dateisystem zu virtuellen "Routen" abgewandt habe.

Wenn Sie mit 'old school' PHP arbeiten, haben Sie 1000 PHP Seiten), Sie haben 1000 PHP Dateien, die diese Seiten darstellen. Jede dupliziert Header/Die Fußzeile enthält und möglicherweise eine andere Logik. Nehmen wir an, Sie müssen das ändern. Was für ein Durcheinander Sie jetzt haben! Sie müssen entweder alle 1000 Dateien ändern, oder Sie haben ein Durcheinander von sehr hässlichem Code in der Kopfzeile/Fußzeilen, um alle Fälle zu behandeln. Unter Verwendung virtueller Routen sind Ihre Kopf-/Fußzeilenlogik, Datenbankverbindungslogik und andere Initialisierungen enthalten einmal, Punkt. Viel besser zu bearbeiten.

Ein weiterer Grund ist die Vermeidung von Mehrdeutigkeiten. Wenn Anwendungen wachsen, werden die Kopf- und Fußzeilen, die aufgenommen werden, komplexer. Sie hatten normalerweise eigene verschachtelte Includes, die von verschiedenen Dingen abhingen. In der Datei PHP für die 'Seite' sind häufig Unklarheiten darüber aufgetreten, ob eine Variable isset () ist oder nicht. Mithilfe virtueller Routen und einer Anwendung, in der bei jedem Laden der Seite alles geladen wird, was Sie benötigen Sie haben diese Sorge nicht mehr.

Schließlich (obwohl es andere Gründe gibt, aber es ist der letzte, den ich auflisten werde) stellen viele dieser 1000 Seiten Code dar, der dupliziert werden würde. Nach dem Refactoring in einen geeigneten Satz von Klassen und Vorlagen wird der Code erheblich vereinfacht, und Sie können alles tun, was Sie möchten, ohne über diese 1000 Dateien zu verfügen.

8
GrandmasterB

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 bedenkt, dass die Vorteile die Kosten als gegeben ü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 sicherlich offen dafür wäre, darüber aufgeklärt zu werden.

Zumindest meiner Erfahrung nach wurde dies anfangs häufig über die Apache-Konfiguration durchgeführt - und vermutlich haben dies auch andere Webserver unterstützt. Konzeptionell gibt es jedoch keinen guten Grund, warum der Server damit beauftragt werden sollte. Schließlich sind die Routen spezifisch für die tatsächliche Anwendung, daher ist es sinnvoll, sie dort zu definieren.

Dies hat sich global geändert, aber wie Sie betonen, schrittweise. Der Grund dafür ist mit ziemlicher Sicherheit sehr einfach: Gute Ideen verbreiten sich über die Zeit. Dies ist auch der Grund, warum es nicht so überraschend ist, dass die Änderung weltweit stattgefunden hat. Es ist nicht so, dass alle zusammengekommen sind und beschlossen haben, es so zu machen. Vielmehr hat jedes Projekt diesen Ansatz angepasst, als es für vorteilhaft gehalten wurde (und Projekte, die ihn nicht unterstützten, verschwanden schließlich).

5
doubleYou

Die RFCs haben die Konzepte bereits von Grund auf mit URIs (die keine Semantik an den lokalen Teil anhängten) und URLs als Sonderfall erstellt, die eine 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 ist 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 Der bereits vorhandene Wertspeicher 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 Aufwand, die Anwendung auszuführen, und die Integration der URL-Dekodierung erleichtert die Implementierung vieler Funktionen und senkt die Kosten.

1
Simon Richter

Zu Beginn der Zeit wurden URLs direkt Dateipfaden auf dem Server zugeordnet, da dies einfach ist und es sowieso keine andere Möglichkeit gibt, oder? Wenn ich nach /path/to/index.php Frage, erhalte ich /path/to/index.php Ausgehend vom Stammverzeichnis der Website (normalerweise nicht vom Server selbst, die Website sollte in einem Verzeichnis oder einem Unterverzeichnis weiter unten aufbewahrt werden ).

Dann, nach ein paar Jahren, lernten wir etwas über das Umschreiben, das eine andere Ressource bietet als die, nach der anscheinend gefragt wurde. /request/path/to/index.php Kann tatsächlich /response/path/to/index.php Dienen.

Ein weiterer Trick ist das Verstecken von index.php. Wenn ich nach /index.php?foo=bar&baz=qux Frage, kann der Server antworten, indem er index.php Wie folgt ausblendet: /?foo=bar&baz=qux, Während er tatsächlich index.php Serviert.

Der nächste wichtige Schritt ist, dass wir gelernt haben, alle URLs auf /index.php Umzuleiten. Jetzt wird /path/to/some/page Im Stillen zu /index.php?path/to/some/page Weitergeleitet. Dies ist etwas schwierig, 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 zu suchen.

Jetzt, da wir dies haben, müssen wir ganz anders darüber nachdenken, 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 verfügbar waren, wie z. B. eine standortweite Benutzerauthentifizierung, eine einheitliche Anwendung von Kopf- und Fußzeilen und Stilen usw.

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

Dies ist ein großer Sprung, da Sie nicht mehr anhand der URL feststellen können, welcher Code ausgeführt wird. Sie müssen jetzt ein tiefes Verständnis dafür haben, wie Ihr spezielles Framework URL-Pfade in Codepfade übersetzt. Obwohl es Ähnlichkeiten zwischen Frameworks gibt, sind die meisten so unterschiedlich, dass Sie einige Kenntnisse benötigen, um mit dem Code arbeiten zu können.

Kurz gesagt, es war eine allmähliche 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.

1
CJ Dennis