必要に応じて、たとえばウィキペディアで主要なアイデアに慣れることができます 。
この考えを明確にし、いくらか再考してみます。
拡張機能
ファイル拡張子とは何ですか？ これは、大まかに言って、このファイルのMIMEタイプの短いエイリアスです。 たとえば、ファイルの拡張子がgifの場合、ファイルの内容は画像/ gifタイプに対応し、htmlがtext / htmlの場合、jsがtext / javascriptの場合などになります。
通常、結果は期待どおりです。 ただし、例外があります。
vkontakte.ru/newsfeed.php
ru.msn.com/iat/us_ru.aspx
www.opennet.ru/cgi-bin/opennet/man.cgi
リクエストには何が見えますか？ php、aspx、およびcgi。 そして、見返りに何を得るのでしょうか？ 右、テキスト/ html。
なぜそうですか？ 理由は明らかです。 サーバーでは、実際にはphp、aspx、およびcgiです。 html-itは「外側」にのみ見えます。 もちろん、これらのファイルを別の正しい拡張子で表示することはありません。 しかし、これは通常行われません。 これは問題ではないと考えられているためです-ユーザーは気にしません（少なくとも私たちはそう考えることに慣れています）。また、開発者と管理者にとっては簡単です。
この問題を解決に値するものとみなすかどうかは未解決の問題です。 しかし、少なくともそれを主張することができます
Web上のhtmlファイルの拡張子は、通常、ユーザーに有用な情報をもたらすだけでなく、直接誤解を招くものです。
フォルダー、ファイル、およびページ
フォルダーとは何ですか？ これは、簡単な方法であれば、ファイルをグループ化する方法です。 また、サイトのコンテキストでのフォルダーとは何ですか？ 答えは、一見すると思われるほど明白ではありません。
はい、Webサーバー側では、これは依然としてファイルをグループ化する方法です。 しかし、これはユーザーにとってそうですか？ いいえ、そうではありません。 そして、ここに理由があります。
私は、ユーザーがサイトをファイルシステムの一部として、異なるファイルやフォルダーのセットとして認識していないことを主張することができます（主に非ギークユーザーの個人的な経験に依存しています）。 ユーザーのサイトは、接続されたページのコレクションです。 はい、もちろん、ページはファイルのままです。 HTTPコンテキストでは、htmlファイルは注目に値するものではなく、pngまたはjsとまったく同じファイルです。 また、HTTPはページについて何も知りません。
TCP / IP、HTTP、およびHTMLについて何も知らないユーザーにとって、違いは非常に大きくなります。 ページは、写真、ボタン、リンクを備えた一種の魔法の物質です。 ファイルは単なるファイルです。 ダウンロードして、他のファイルの隣に配置することができ、それらと違いはありません。 もちろん、そこには独自の魔法がありますが、インターネット（読み取り、ウェブ）とは関係ありません。 このページは、ブラウザが開いている間のみ存在します。 はい、ダウンロードすることもできますが、インターネットのすべての特別な魔法が消えます-リンクはクリックを停止し、ボタンはクリックして見て、「インターネット上」とは完全に異なるでしょう。 一般的に、それはデッドページになります。
そのため、ページはファイルではありません。 ページはページです。
しかし、ファイルがファイルではなくなった場合、フォルダーとは何ですか？ ファイルはありませんが、フォルダーはありますか？ フォルダーを調べて、そこにあるファイルを確認できます。 そして、ここでは不可能です。 試してみると、その内容ではなく、別のページが表示されます。 それで、このフォルダは何ですか？ そして、これはフォルダーではありません。 このページは。
つまり、ユーザーがファイルを要求した場合とフォルダーを要求した場合に、結果としてページが表示されても違いはありません。
そして違いがなければ、なぜそれらを区別するのですか？ それらを区別する必要はありません。拡張機能を放棄する必要があります。最後にスラッシュを付けてクエリを実行し、クエリを互いに同義語にする必要があります。
/news.php-明確ではありません（答えはphpではなくhtmlであるため、真実ではありません）
/ニュース-はるかに良い
/ニュース/-とても良い
後者のオプションは、Google、Habr、およびLebedev Studioで使用されます。 まるでヒント:)
ページはファイルやフォルダーではなく、ページはページです。
パラメータ
要求パラメーターは、人間の了解度の主な敵です。 実際、CNCはまずURLのパラメーターからユーザーを保存するために呼び出されます。 可能であれば。
ここに追加することはあまりありません。 はい、いです。 はい、判読できません。 はい、削除する必要があります。
しかし、残念ながら、これは常に可能とは限りません。 完全に放棄したいのですが、うまくいきません。 複雑なグリッドでは、たとえば、何らかの方法でパラメーターがありません。
/catalogue.php?sect=11&kind=6-ugい
/カタログ/ 11/16 /-少し改善（Wikipediaの例）
/カタログ/ライト/電球/-すでに良好（この例は現在ウィキペディアにもあります）
パラメータは人間の了解度の主な敵です。
言語
別の重要なポイントがあります。これは、何らかの理由で、通常は省略されています。CNCについては、これがurlの言語です。 自然言語（通常は英語）。
Art。Lebedev StudioのWebサイトである（ほぼ）理想的なCNC実装の例を見てみましょう（ちなみに、記事を書いているときのみ、htmlファイルの拡張子を拒否していることがわかりました。最近では、PHPやpyではなく、正直なhtml）：
www.artlebedev.ru/everything/optimus
素晴らしいURL。 しかし、それでも、彼の何かがおかしいのですよね？ 目をほとんど痛めないものがあります。 それで何？
ただし、アドレスの一部は、セクション/ページの名前に完全には対応していません。 「Our Everything」セクションは、URLに「everything」という単語が表示され、Optimusキーボードに関するページに「optimus」という単語が表示されます。
サイトの言語はロシア語のみです。 つまり、サイトを使用するには、ロシア語でロシア語のみを知っている必要があります。 一方、URLはすべて英語です。 つまり、サイトを使用するにはロシア語を知っているだけで、CNCのアメニティを使用するには英語も必要です。 さらに、私はこれのためだけに彼を必要とします。
奇妙な例外、あなたは見つけませんか？
すべての名前は、サイトのコンテンツに関して外国語で複製されます。 どんな目的のために？ これは便利です。 いや 明らかに？ いや
/ all / optimus /と書いてみませんか？ または、/すべて/オプティマス/。
これは、ウィキペディアのほか、すべてのウィキメディア財団プロジェクトおよびMediaWikiに基づいた他のサービスです。
はい、URLのキリル文字には明らかな問題があります。 このようなリンクをメールまたはインスタントメッセンジャーで送信する際の問題。 ブログやフォーラムでそのようなリンクを引用する際の問題。 はい、問題はありますが、それらはほとんどありません。これは、ナビゲーションに役立つ美しく、わかりやすく、明白なURLにはあまりないようです。
PS。 理論に焦点を合わせるために、このようなURLを実装する際のすべてのニュアンスを意図的に省略しました。 実装は、必要に応じて、別のトピックで説明できます。 欲望がありますか？ :)
PPS トピックをシフトする方が良い場所を教えてください、私はWeb標準よりも良いものを思いついていませんでした。