URLルートをファイルシステムから分離するために、現代のWebアプリケーションフレームワークはどのように、そしてなぜ進化したのですか？

約10年前と比較して、URLパスをファイルシステムから切り離すルーティングのスタイルを使用するフレームワークへの移行に注目しています。これは通常、フロントコントローラーパターンの助けを借りて達成されます。

つまり、以前は、URLパスはファイルシステムに直接マップされていたため、ディスク上の正確なファイルとフォルダーを反映していましたが、最近では、実際のURLパスは構成によって特定のクラスに向けられるようにプログラムされているため、ファイルを反映しなくなりましたシステムフォルダとファイル構造。

質問

どのようにして、なぜこれが当たり前になったのですか？かつて一般的なファイルへの直接アプローチが事実上放棄された時点まで「より良い」と判断した理由は何ですか。

その他の回答

ここには、ルートの概念といくつかの利点と欠点に少し似た答えがあります：PHPフレームワークでは、なぜ「ルート」概念が使用されるのですか？

しかし、これは、この新しいルーティングスタイルパターンを使用して現在の新しいプロジェクトがほとんど行われており、ファイルへの直接書き込みが古くなったり放棄されたりする、歴史的な変化の側面、またはこの変化が徐々に起こった方法や理由については扱っていません。

また、言及されたこれらの利点と欠点のほとんどは、そのような世界的な変化を正当化するほど重要ではないようです。この変更を推進している唯一のメリットは、おそらくファイル/フォルダーシステムをエンドユーザーから隠すことと?param=value&param2=value、URLが少しきれいに見えるようにすることの欠如です。しかし、それらが変更の唯一の理由でしたか？そして、はいの場合、なぜそのような理由があったのですか？

例：

私はPHPフレームワークに最も精通しており、多くの人気のある現代のフレームワークはこの分離されたルーティングアプローチを使用しています。それを機能させるには、Apacheまたは同様のWebサーバーでURL書き換えを設定します。通常、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/

ララヴェル

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

CakePHP

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

最も基本的な形式では、Webサイトは静的ファイルを提供します。URLパスをファイルパスにマッピングすることが最も明白な選択肢です。基本的に、読み取り専用のFTPサイトです。

その後、人々はスクリプトを使用してページのコンテンツを変更したいと考えました。最も簡単な方法は、スクリプト言語をページに埋め込み、インタープリターを介して実行することです。繰り返しますが、既に存在するパス->ファイルパスルーティングを考えると、これは非常に簡単でした。

しかし、実際には、インタープリターへの引数としてそのファイルを実行しています。要求が静的ファイルに対するものであり、解釈する必要があるものに対するものである場合を識別する必要があります。

より高度なコンパイル言語の使用を開始すると、ファイルの場所からさらに離婚します。

さらに、Webサーバーは既に静的ファイルをキャッシュし、あらゆる種類の最適化を行っています。つまり、ファイルシステムへのアクセスはルールではなく例外です。この時点で、古いリンクファイルシステムのパスは、ヘルプというよりも障害です。

しかし、実際の海の変化は、ユーザーがパスからファイル拡張子を取り除きたいときに来たと思います。myPage.aspまたはmyPage.phpを取得することは、「普通の」人々を混乱させ、SEOを妨害するものでした。

ユーザーにはパスが表示されるため、WebのUIの一部になっているため、技術的な制限がまったくないようにする必要があります。私たちは「www」を失い、事実上すべてが「.com」です。複数のURLは同じページを指します。

mydomain.com/sale対www.mydomain.co.uk/products/sale.aspxで収益を上げる場合、技術的な制限が邪魔にならないようにします。

あなたは上のロイ・フィールディングでホワイトペーパーを見ることができるのRepresentational State Transfer（REST）のようときとその理由。リソースとファイルを区別した最初のフレームワークは、Ruby on Railsでした。URLからコードへのルーティングの概念が導入されました。

変革的であるRESTの背後にある主な概念は次のとおりです。

• URLはリソースを表します
• そのリソースは複数の表現を持つことができます
• アプリケーションが再構築された場合、URLは壊れてはいけません
• アプリケーションはウェブのステートレス性を取り入れるべきです

ファイルをURLから直接提供する主な欠点は、次の問題が発生することです。

• Webサイトが再編成されるため、リソースリンクは常に壊れています
• リソースと表現は結びついています

私もいくつかの公正なバランスを提供することが重要だと思います：

• すべてのリソースの重要度が等しいわけではありません。そのため、スタイルベースのリソース（CSS、JavaScript / EcmaScript、画像）が直接提供されます。
• 単一ページのアプリをより適切にサポートするHATEOASなどのRESTの改良版があります。

私はそれが現代のウェブアプリケーションフレームワークのアーティファクトだとは思わない、それは一般的に一般に動的なページ提供のアーティファクトだ。

で昔のソフトウェアは、そのパスによってファイルシステムから個々のファイルを務め、主に静的なWebページは、ありました。URLパスのファイルシステムパスへの1：1マッピング（1つのディレクトリがWebルートとして指定されている）が明らかな選択であったため、彼らは主にそうしました。

その後、動的コンテンツを提供する時代が来ました。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をファイルパスにマッピングするこのアプローチが、ファイルパストラバーサルを介した大量の偶発的なデータのリリースにつながる可能性があることです。

パスをファイルシステムにマップする場合、要求として受信するすべてのパスが、クライアントからアクセスできるファイルにマップされることを確認する必要があることを意味します。発生していないことを保証する簡単なアプローチは、透過的なマッピングを削除し、より明示的に行うことです。

これはPHPのみの問題ではありません。ここでの証拠として、Apache強化ガイドの関連セクションがあります。

業界に答えることはできませんが、なぜ2000年前半にURL =ファイルシステムから仮想「ルート」に移行したのかを説明できます。

「古い学校」のPHPを使用すると、1000のPHPページがある場合、それらのページを表す1000のPHPファイルがあります。複製するヘッダー/フッターにはそれぞれ、場合によっては他のロジックが含まれます。次に、それを変更する必要があるとしましょう。あなたは今、あなたの手に何と混乱しています！1000個すべてのファイルを変更するか、すべてのケースを処理するためにヘッダー/フッターに非常にいコードの寄せ集めが必要になります。仮想ルートを使用すると、ヘッダー/フッターロジック、データベース接続ロジック、およびその他の初期化が1回、期間に含まれます。一緒に作業する方がずっといい。

もう1つの理由は、あいまいさを避けるためです。アプリケーションが成長するにつれて、含まれるヘッダー/フッターはより複雑になります。通常、さまざまなものに依存する独自のネストされたインクルードがありました。「ページ」のPHPファイルでは、変数isset（）かどうかについてあいまいな点がよくあります。仮想ルートを使用し、必要なすべてがページのロードごとにロードされるアプリケーションを使用すると、その心配はなくなります。

最後に（他の理由もありますが、最後にリストします）、これらの1000ページの多くは複製されるコードを表しています。したがって、クラスとテンプレートの適切なセットにリファクタリングした後、コードは大幅に簡素化され、これらの1000個のファイルがなくても、必要なすべてを実行できます。

この分離が有益な理由については、あまり詳しく説明しません。主な論点は、セマンティクス（実際にアクセスしようとしているもの）を基礎となる実装から分離することです。

メリットがコストを上回ることを考えると（これは別の質問になりますが）、徐々に採用された理由を見るのは難しくありません。私はこれを引き起こした単一のイベントがあるとは思わないが、私は確かにこれについて教育されることに開放的だろう。

少なくとも私の経験では、最初はこれは多くの場合Apache構成を介して行われました。おそらく他のWebサーバーもこれをサポートしていました。ただし、概念的には、サーバーにこれを割り当てる理由はありません。結局、ルートは実際のアプリケーションに固有であるため、そこで定義することは理にかなっています。

これはグローバルに変更されましたが、ご指摘のとおり、徐々に変わりました。その理由はほぼ間違いなく非常に単純なものです。良いアイデアは時間とともに広がります。これはまた、変化が世界的に起こったことはそれほど驚きではない理由です。全員が集まって、このようにすることを決めたわけではありません。むしろ、すべてのプロジェクトが有益であると考えたときにこのアプローチを採用しました（そして、それをサポートしなかったプロジェクトは最終的に姿を消しました）。

RFCは、URI（ローカル部分にセマンティクスを付加しなかった）、およびパスのようなセマンティクスを導入した特別なケースとしてURLを使用して、HTML文書が文書に関連するリンクを使用できるように、概念を最初から構築しましたベースURL。

明らかな実装は、URLのローカル部分をファイルシステムに直接マップすることです。したがって、これは単純なセットアップが行ったことです。専用のリレーショナルデータベースを使用してドキュメントを検索するか、高度に最適化された低オーバーヘッドキーを利用するか既にお持ちのバリューストアは外部にとって重要ではありませんが、ドキュメントを提供するためのコスト構造に確かに影響します。

永続データを使用するWebアプリケーションがある場合、そのコスト構造は変化します。アプリケーションを実行するオーバーヘッドが常にあり、URLデコードを統合することで多くの機能を実装しやすくなり、コストが削減されます。

最初は、URLがサーバー上のファイルパスに直接マップされていました。これは簡単であり、とにかく他の方法がないためです。を要求すると、Webサイトのルートディレクトリから開始し/path/to/index.phpます/path/to/index.php（通常はサーバー自体ではなく、Webサイトはさらに下のディレクトリまたはサブディレクトリに保持する必要があります）。

それから数年後、私たちは書き換えについて学び始めました。それは明らかに要求されたものとは異なるリソースを提供しています。/request/path/to/index.php実際に役立つことができ/response/path/to/index.phpます。

別の秘trickは隠れているindex.php。/index.php?foo=bar&baz=quxサーバーに次のように非表示にすることで応答できるように要求すると、index.php：とにかく/?foo=bar&baz=qux実際にサービスを提供しindex.phpます。

次のステップは非常に重要なステップですが、すべての URLをにリダイレクトすることを学びました/index.php。だから、今、/path/to/some/page静かにリダイレクトされ/index.php?path/to/some/pageます。通常、各スラッシュは新しいサブディレクトリを表すため、これは少し注意が必要ですが、この場合、Webサーバーはパスを検索する代わりにパラメーターとして送信するように構成されています。

これができたので、ウェブサイトがどのように構成されているかについて、まったく異なる考え方が必要です。以前は、さまざまなページの緩やかなコレクションでした。現在、すべてが単一のエントリページを介してルーティングされます。これにより、サイトはさらに複雑になりますが、サイト全体のユーザー認証、ヘッダー、フッター、スタイルの均一な適用など、以前は利用できなかった機会が提供されます。

これにより、数百または数千のアプリWebサイト（各ファイルを独自のアプリと見なす場合）を、1つのはるかに複雑ではあるがはるかに一貫したアプリに効果的に変えます。

これは大きな飛躍です。URLを見ただけでは、どのコードが実行されるのか分からなくなるからです。ここで、特定のフレームワークがURLパスをコードパスに変換する方法を深く理解する必要があります。フレームワークには類似点がありますが、ほとんどはコードと連携するためにある程度の知識が必要なほど十分に異なっています。

簡単に言えば、それは発見の漸進的な進化であり、突然のジャンプではなく、各開発者はほぼ同じ発見の旅をしなければなりませんでした。学習曲線は非常に急です。ただし、抽象的な概念を本当にすばやく把握できない限りです。

長い間webdevとして、HTML5の時代にナビゲーションなしの履歴制御（history.pushState()）が登場したことで、これが実用的になったと思います。その前に、フラグメント（/path#fragment）のみを更新しない限り、ページをリロードしてURLバーを更新する必要がありました。このフラグメントはサーバーには見えないため（ルーティングされません）、動的ページを更新またはブックマークする唯一の方法はJavaScriptを使用することでした。

これはSEOに大きな影響を与え、Google が物理ハッシュへの動的ハッシュのサーバー側マッピングを必要とするめったに使用されない「ハッシュバン」スキーマを開発するように導きました。これは扱いにくいものであり、ロボット間で普遍的ではないため、「スパイダーはAjaxコンテンツをクロールできない」という（誤った）公理を導きました。しかし、Ajaxコンテンツの利点は明確です。たとえば、JSなしのGoogleマップを使用してみてください。

解決策は、ページをリロードせずに、サーバー上でミラーリングできる値でブックマークを更新したり、JSなしで更新したりして、URLバーを更新する方法でした。この機能が利用可能になると、開発者は「メインコンテンツセクション」、URLバー、ブレッドクラムを更新するだけでサイトを「ナビゲート」できます。これは、すべてのJS + CSSが再フェッチ+解析される必要がなく、ページ間転送を大幅に高速化できることを意味していました。