URLの仕組みが少し混乱しています。昔、HTMLなどを学習していたとき、ドメイン名の後に続くのはロードするファイルの場所（たとえば、website.com / somefolder / somefile.html）であることを知っていました。そして、それは簡単で、理解できました。
最近、私はウェブについてもう少し学ぶ必要があり、URLがより複雑であることがわかりました。例えば：
それはどのように機能しますか？サーバー（または他の何か？私はまったく初心者）は、リクエストを受け取ったときにURLが何を意味するのかをどのように知っていますか？かもしれない：
私の質問が理にかなっているかどうかはわかりませんが、私の混乱が何であるかを理解してください。
回答:
それはどのように機能しますか？
サーバーが決定します。
サーバー（または他の何か？私はまったく初心者）は、リクエストを受け取ったときにURLが何を意味するのかをどのように知っていますか？
サーバーはその構成に依存しています。Unixベースのサーバーでは、これはしばしば「構成」ファイルと呼ばれる1つ以上のテキストファイルによって処理されます。サーバーをセットアップするときに、これを指定できます。これを指定する方法の詳細は、使用するWebサーバーソフトウェアによって異なります。
（一般的なWebサーバーとCGIパッケージに関するチュートリアルがたくさんある傾向があるため、Webサイト管理者がこれを行う方法を知らない場合、その人は一般に例/ドキュメント/チュートリアルを読み始めます。 ApacheなどのWebサーバーでは、Drupalのセットアップに関する情報を見つけることができます。一方、Drupalなどの情報を調べると、Apacheを構成する方法に関するドキュメントのセクションを見つけることができます。 Drupalを使用します。多くのドキュメントが用意されているため、Webサイト管理者は通常、使用したいソフトウェアパッケージに関連する詳細を見つけるためにそれほど苦労する必要はありません。
HTTP 1.1クライアントは、URLを3つの部分に分割する傾向があります。
それは少し単純化しすぎかもしれません。いくつかの古いURLでは、ftp：// username @ password：example.com/somedir/fileのようなものを許可していましたが、新しいWebブラウザーは、MS KB 8344389などのセキュリティ上の懸念からこのようなサポートを削除する傾向がありました（顕著な悪用を含むたとえば、http： //paypal.com/gibberish%40PhishingSite.example.com/gibberishは％40をASCII 64（@）に変換し、Paypal.com / gibberishのユーザー名を使用してPhishingSiteにログインします.example.comは単純にログインを受け入れ、PayPalのパスワードを尋ねます。人々はURLの先頭にpaypal.comを見て、それを信頼します。
確かに、URLの＃はWebクライアントが認識し、サーバーに送信しないもののような「標準」があります。代わりに、Webクライアントは、＃の後のテキストを、ジャンプ先のアンカーテキストとして扱います。また、％は16進文字のエスケープに使用されます。Webクライアントはそれを理解する傾向があります。
その他の詳細はサーバー次第です。たとえば、多くのWebサーバーには？パラメーターのリストを開始し、パラメーターリスト内のパラメーターを分割するために＆（または多くのセミコロン？）を使用します。ただし、これは多くのWebサーバーが示す一般的な動作です。Webサーバーにそれを強制するHTTPの部分はありません。実際、WebサーバーはWebサーバーが必要とする処理を処理でき、Webクライアントはそのための特別なサポートを必要とする可能性はほとんどありません。
HTTPサーバーをセットアップしたことがある場合、その構成の一部が、要求されたリソースをどう処理するかを指定していることを理解するでしょう。たとえば、/に送信されるものはすべて、/ cgi-bin /にあるプログラムを実行する/ cgi-bin /および/ scriptsの下にあるものを除き、ローカルハードドライブの/ srv / httpdocs /エリアからファイルをロードします。 /で終わる.plは、PERLインタープリターによって実行されます。
具体的な詳細は、Webサーバーの構成によって異なるため、静的なページのコピーまたは実行されるプログラムの出力を受信することが保証されるかどうかをWebクライアントに伝える普遍的な標準はありません。Webクライアントが期待できるのは、Webクライアントがリソースを要求すると、Webサーバーがそれに応答することだけです。
Webサーバーはこれらの意味を認識しません。すべての場合において、リソースパスを受け取り、Webサイトのメインプログラムを介して実行し、結果の出力を送信します。そしてもちろん、異なるプログラムは、与えられたパスで異なることをします。
プログラムが設定されていない場合、その名前のファイルを探して直接提供します。（PHPとCGIはしばしば中間にあります。Webサーバーはまだファイルを探しますが、そのファイル自体をプログラムとして実行します。）
その/node/43ため、「Drupalビュー」になるのは/node/<anything>、Drupalソフトウェアに渡すように設定されたWebサーバーだけです。Webページは、動的に生成されているにもかかわらず、リソースと見なされます。
（もちろん、Drupal自体は、パスが/node/それで始まる場合、ビューIDが後に続くことを知っています。）
REST要求も完全に定期的なリソース要求です。それらを「RESTful」にするのは、全体的なスタイルと動作です。（たとえば/book/345、RESTイデオロギーに適合するスタイルのURL、そうではあり/api/get_book?id=345ません。）