最新のWebアプリケーションフレームワークが進化し、URLルートをファイルシステムから切り離すようになったのはなぜですか。
約10年前と比較して、ファイルシステムからURLパスを切り離すルーティングのスタイルを使用するフレームワークへのシフトに気づきました。これは通常、フロントコントローラーのパターンを使用して実現されます。
つまり、以前は、URLパスがファイルシステムに直接マップされていたため、ディスク上の正確なファイルとフォルダーが反映されていましたが、現在では、実際のURLパスは、構成を介して特定のクラスに送られるようにプログラムされているため、ファイルを反映していませんシステムフォルダとファイル構造。
質問
なぜ、なぜこれが当たり前になったのですか？かつて一般的だったファイルへのダイレクトアプローチが効果的に放棄されるまで、「より良い」と判断されたのはなぜですか、なぜですか。
その他の回答
ルートの概念といくつかの利点と欠点に少し入った同様の答えがここにあります：PHPフレームワークで、なぜ「ルート」なのか"使用するコンセプトは？
しかし、これは、歴史的な変更の側面、またはこの変更が徐々に起こった方法または理由に対処していません。最近の新しいプロジェクトでは、この新しいルーティングスタイルのパターンがほとんど使用されており、ファイルへのダイレクトは古くなっているか破棄されています。
また、言及されているこれらの利点と欠点のほとんどは、そのような地球規模の変化を正当化するのに十分重要ではないようです。この変更を推進するために私が見ることができる唯一の利点は、おそらくファイル/フォルダーシステムをエンドユーザーから隠すことであり、?param=value¶m2=valueは、URLを少しきれいに見せます。しかし、それらが変更の唯一の理由でしたか？そして、もしそうなら、なぜ理由の背後にあったのですか？
例：
私はPHPフレームワークに最も精通しており、多くの一般的な最新のフレームワークはこの分離ルーティングアプローチを使用しています。それを機能させるには、Apacheまたは同様のWebサーバーで RL rewriting を設定します。通常、Webアプリケーション機能がファイルへのダイレクトURLパスを介してトリガーされなくなります。
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
最も基本的な形式では、Webサイトは静的ファイルを提供します。 URLパスをファイルパスにマッピングすることが最も明白な選択です。基本的に、それは読み取り専用のFTPサイトです。
次に、スクリプトを使用してページのコンテンツを変更したいと考えました。最も簡単な方法は、スクリプト言語をページに埋め込み、インタープリターで実行することです。繰り返しますが、既存のパス->ファイルパスルーティングを考えると、これは十分に単純です。
しかし、実際には、このファイルをインタープリターの引数として実行しています。リクエストが静的ファイルに対するものであるか、それが解釈する必要があるものに対するものであるかを識別する必要があります。
より高度なコンパイル済み言語の使用を開始すると、ファイルの場所からさらに離れます。
さらに、Webサーバーはすでに静的ファイルをキャッシュしており、あらゆる種類の最適化を行っています。つまり、ファイルシステムにアクセスすることは、ルールというよりも例外です。この時点で、古いリンクファイルシステムのパスは、ヘルプというよりも邪魔になります。
しかし、ユーザーがパスからファイル拡張子を取り除きたいときに、本当の大きな変化が起こったと思います。 myPage.aspまたはmyPage.phpを取得することは、「通常の」人々を混乱させ、SEOを妨害するものでした。
ユーザーにはパスが表示されるため、パスはWebのUIの一部になり、そのため、技術的な制限を完全に排除する必要があります。 「www」を失い、事実上すべてが「.com」です。複数のURLが同じページを指します。
Mydomain.com/saleとwww.mydomain.co.uk/products/sale.aspxを組み合わせて収益を上げた場合、技術的な制限が邪魔になりたくありません。
Roy Fieldingのホワイトペーパーを見ることができます REpresentational State Transfer（REST） （whenおよびなぜ。リソースとファイルを区別する最初のフレームワークはRuby on Rails）で、URLのコードルーティングの概念が導入されました。
変革をもたらしたRESTの背後にある主な概念は次のとおりです。
- URLはリソースを表します
- そのリソースは複数の表現を持つことができます
- アプリケーションが再構築された場合、URLは壊れません。
- アプリケーションはWebの無国籍を受け入れる必要がある
ファイルをURLから直接提供することの主な欠点は、次の問題が発生することです。
- Webサイトが再編成されると、リソースリンクが常に壊れる
- リソースと表現が結びついている
私もいくつかの公正なバランスを提供することが重要だと思います：
- すべてのリソースの重要性が同じというわけではありません。そのため、スタイルベースのリソース（CSS、JavaScript/EcmaScript、画像）を直接提供しています。
- REST [〜＃〜] hateoas [〜＃〜] のように改良されており、単一ページのアプリをより適切にサポートします。
modernWebアプリケーションフレームワークのアーティファクトではないと思います。これは、一般に動的ページサービスのアーティファクトです。
昔には、ほとんどの場合静的なWebページがあり、ソフトウェアはパスによってファイルシステムから個々のファイルを提供していました。 URLパスのファイルシステムパス（1つのディレクトリがWebルートとして指定されている）への1：1マッピングが明白な選択だったため、それらは主にそうでしたが、URLの書き換え（たとえば、ファイルの移動後にリダイレクトを行う）も一般的でした。
その後、動的なコンテンツを提供する時代が到来しました。 CGIスクリプト（およびそれらから発展したものすべて）は、ある種のデータベースに支えられて、ページをその場で作成しました。 en.wikipedia.org/w/index.php?title=Path_(computing) のように、URLのGETパラメータが一般的になりました。
ただし、パスセグメントのみで構成された読み取り可能なURLを使用する方がユーザーフレンドリーです。したがって、動的アプリケーションは単純なパス（たとえば en.wikipedia.org/wiki/Path_(computing) ）をパラメーターにマップし、これらのマッピングは「ルート」と呼ばれます。
このアプローチは、ユーザビリティの重要性がより広く認識され、SEOの一部となったときに人気を得たため、より最近のように感じられるかもしれません。これがおそらく、それが大きなWebフレームワークに直接組み込まれた理由です。
1つの理由は、リクエストごとにディスクからファイルをロードするのが遅いため、Webサーバーがファイルをメモリにキャッシュする方法を作成し始めたので、とにかくそれをメモリに保持しようとする場合、それがどこにあるかが重要なのはなぜですかディスク？
1つの理由は、多くのWebフレームワークがコンパイルされた言語で記述されているため、ディスク上にファイル構造がなく、jarファイルなど何でもないためです。解釈された言語は、コンパイルされた言語から気に入ったアイデアを借用しました。
1つの理由は、https://softwareengineering.stackexchange.com/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routesのような、よりセマンティックで動的なルートが必要であることです。明らかに、/var/www/questions/363517/how-and-why-did-modern-web-application-frameworks-evolve-to-decouple-url-routes.phpファイルは必要ありません。このようなルートを作成するために、Webサーバー構成でURL書き換えルールを作成していた。これは単なるコード変更であり、操作ははるかに簡単です。
主な理由の1つは、URIをファイルパスにマッピングするこのアプローチが File Path Traversal を介して大量のデータを偶発的に解放したことであると考えられます
パスをファイルシステムにマップする場合、要求として受け取るすべてのパスが、クライアントからアクセスできるファイルにマップされていることを確認する必要があることを意味します。発生していないことを保証する簡単な方法は、透過的なマッピングを削除し、より明示的に行うことです。
これはPHPのみの問題ではありません。ここでの証拠は、 Apache強化ガイド の関連セクションです。
業界についてはお答えできませんが、2000年代の初めに仮想の「ルート」に向けてURL =ファイルシステムから離れた理由をお話しします。
「古い学校」のPHPで作業している場合、1000 PHP=ページがある場合、それらのページを表す1000 PHPファイルがあります。各ヘッダーが重複しています/フッターには、場合によっては他のロジックが含まれています。今、それを変更する必要があるとしましょう。手に持っているのはなんと厄介です！1000個すべてのファイルを変更する必要があるか、ヘッダーのごちゃごちゃしたコードがごちゃごちゃしてしまいます/ footersすべてのケースを処理します。仮想ルートを使用すると、ヘッダー/フッターロジック、データベース接続ロジック、およびその他の初期化が含まれますonce、ピリオド。
もう1つの理由は、あいまいさを避けるためです。アプリケーションが成長するにつれて、含まれるヘッダー/フッターはより複雑になります。彼らは通常、さまざまなことに依存する独自のネストされたインクルードを持っていました。 PHPファイルで、変数isset（）かどうかについて曖昧に遭遇することがよくあります。仮想ルートを使用し、必要なすべてが各ページのロードでロードされるアプリケーションを使用する、あなたはもはやその心配はありません。
最後に（他の理由もありますが、これが最後に挙げます）、これらの1000ページの多くは重複するコードを表しています。したがって、適切なクラスとテンプレートのセットにリファクタリングした後、コードは大幅に簡略化され、それらの1000個のファイルがなくても、やりたいことをすべて実行できます。
この分離がなぜ有益であるかについては、あまり詳しく説明しません。主な論点は、セマンティクス（実際にアクセスしようとしているもの）を基礎となる実装から分離することです。
メリットを与えられたコストよりも上回っていることは、これは別の質問ですが、それが徐々に採用された理由を理解することは難しくありません。これを引き起こした単一のイベントがあるとは思いませんが、私は確かにこれについて教育を受けることにオープンです。
少なくとも私の経験では、最初はこれはしばしばApache構成を介して行われました-おそらく他のWebサーバーもこれをサポートしていました。ただし、概念的には、サーバーにこれを課すべき理由はありません。結局のところ、ルートは実際のアプリケーションに固有なので、そこで定義することは理にかなっています。
これは世界的に変わりましたが、あなたが指摘するように、徐々に。これの理由は、ほぼ間違いなく非常に単純なものです。優れたアイデアは時間とともに広がります。これが、変化が世界的に起こったのはそれほど驚くべきことではない理由でもあります。みんなが集まってこのようにすることに決めたわけではありません。むしろ、すべてのプロジェクトが、このアプローチを有益だと考えたときにこのアプローチを採用しました（そして、それをサポートしていないプロジェクトは最終的には姿を消しました）。
RFCは、URI（ローカル部分にセマンティクスを付加しなかった）と、HTMLドキュメントがドキュメントに関連するリンクを使用できるようにパスのようなセマンティクスを導入した特別なケースとしてURLを使用して、概念を最初から構築しましたベースURL。
明らかな実装は、URLのローカル部分をファイルシステムに直接マップすることです。したがって、これは簡単な設定でした—専用のリレーショナルデータベースを使用してドキュメントを検索するか、高度に最適化されたオーバーヘッドの少ないキーを利用するかすでに持っているバリューストアは外部にとって重要ではありませんが、確かにドキュメントを提供するためのコスト構造に影響を与えます。
永続的なデータを持つWebアプリケーションがある場合、そのコスト構造は変化します。常にアプリケーションを実行するオーバーヘッドがあり、URLデコードをそれに統合すると、多くの機能の実装が容易になり、コストが削減されます。