Webを支える技術②~URI~
前回はWebを支える技術の概論として主にRESTについてまとめた。
Webを支える技術①~RESTとは~ - すなのプログラミングノート
今回はその続き、Webを支える技術の3つのうちのURIについて。
- URI
- HTTP
- HTML
URIとはUniform Resource Identifierの略で、「リソースを統一的に識別するID」のこと。
つまり、「同じルールのもと制定された、リソースを一意に指し示すための名前/ ID」のこと。
そのためURIさえあれば全てのリソースに対して簡単にアクセスできる。
ちなみにURLはUniform Resource Locationの略なので、URIとは異なるがまぁ同じと思って差し支えない。
URIの方が広義の意味になる。
URIの構文
URIの構文はよく見るこんな感じのやつ。
http://blog.example.jp/entries/1
これをパーツに分解すると以下のようになる。
- URIスキーム: http
- ホスト名: blog.example.jp
- パス: /entries/1
ホスト名はDNSで名前解決できるドメイン名かIPアドレスで、インターネット上で必ず一意となる。
ちなみにスキームの後の「:」はスキームとその後ろの区切りを示し、「//」はユーザー情報とホスト名の開始を知らせる文字列。
これはよく見る形だが、実はもっと複雑な情報を持たせることもできる。
それがこちら。
http://suna:pass@blog.example.jp:8000/search?q=test&debug=true#n10
めっちゃ複雑になった。。。
さっきの例ではなかったものを挙げると以下のようになる。
- ユーザー情報: suna:pass
- ポート番号: 8000
- クエリパラメータ: q=test&debug=true
- URIフラグメント: #n10
ユーザー情報はリソースにアクセスする際のユーザー情報で、ユーザー名とパスワードを「:」で区切る。
＠の後ろにホスト名が続く。
ポート番号は省略するとデフォルトで、HTTPのデフォルトは80。
クエリパラメータは例えば検索キーワードなど、クライアントから動的にURIを生成する時に利用する。
絶対URIと相対URI
これはディレクトリにおける絶対パス と相対パスと同じ。
相対URIの場合、起点となるURIを設定する必要があり、これをベースURIと呼ぶ。
通常このURIはHTMLなどの中で明示的にベースURIを指定する必要がある。
HTMLの場合は<head>の中に<base>を入れる。
<head> <title>test web page </title> <base href="http://example.jp/" /> ... </head>
URIで使用できる文字
URIの使用で許可されてる文字以外をURIに入れる場合には%エンコーディングでその文字をエンコードする。
「http://ja.wikipedia.org/wiki/あ」のような日本語の物は%エンコードされるため、こんなようなURIになる。
http://ja.wikipedia.org/wiki/%E3%81%82
確かにAmazonのリンクとかよくこんな風になってるの見てたけどそういうことかと納得。
マトリクスURI
サーバ側でURIを設計する際は様々な注意点があるが、あまり自分で使うことがイメージできなかったのでざっくり省略。
ここではマトリクスURIについてのみまとめておく。
URIを設計する際にパスを使うことが多いが、必ずしも階層構造で表現できないものがある。
たとえば地図サービスでは緯度や経度などの他に表示スケールや航空写真かどうかのフラグなど複数のパラメータを組み合わせる必要がある。
このように複数パラメータの組み合わせで表現するリソースにはマトリクスURIを使う。
階層構造の表現は「/」だったが、マトリクスURIでは複数パラメータをそれぞれ「;」で区切る。
以下は一例。
http://example.jp/map/lat=35.705471; lng=139.751898
latが緯度、lngが経度。
現在は一般的にマトリクスURIの表現には「;」か「,」を使う。
使い分けは以下の通り。
「;」: パラメータの順序が意味を持たない場合 「,」: パラメータの順序が意味を持つ場合
URIの不透明性
クライアント側のURIの性質について。
URIは可読性が高いため、ユーザーがURIの構造を推測しやすくなる。
URIの内部構造を推測して操作したりクライアント側でURIを構築したりすべきではない。
なぜなら推測してもそこにリソースがあるとは限らないし、サーバ側の実装でURIの構造を変更した場合に、システムが動かなくなるという密結合状態になるから。
したがって、URIをクライアント側で組み立てたり、拡張子からリソースの内容を推測したりできないことを、「URIはクライアントにとって不透明である」と言う。
クライアントを作る際は、URIを不透明にすべき。
URIに関してはアプリケーションのフレームワーク がやってくれちゃうので、普段意識することはないけどいい勉強になった。
次回はHTTPについて。
Webを支える技術③~HTTP~ - すなのプログラミングノート
参考
Webを支える技術(書籍) https://amzn.to/2AYsEy7
Web技術の基本(書籍) https://amzn.to/2YhQsFX
