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