Webを支える技術 第2部 まとめ

Webを支える技術の第2部をまとめました

第4章 URIの仕様

URIは統一されたリソースの識別子であり、リソースに割り当てれば一意に示すことができる。

URIの基本的な構文

URIは基本的に以下のようなパーツから構成されている。

URIスキーム

URIはまず利用するプロトコル(スキーム)から始まる。上記の場合、HTTPでリソースにアクセスするということが分かる。

ホスト名

次にホスト名が入る。ホスト名は基本的にDNSによって割り当てられた「ドメイン」もしくは「IPアドレス」になり、必ず一意な値となる。(同名のサーバーは存在してはならない)

パス

最後はホスト内のパスを指定する文が入る。これはホストサーバ内のディレクトリ及びファイルを指定するものであり、ホスト名と同様こちらも必ず一意な値となる。

一意なURI

URIのホスト名及びパス値が一意に割り当てられていることによって、世界中の他のリソースと重複しないようになっている。 (現実の住所と同じ。同じ住所の家が複数あった場合、どの家が本物なのか分からない)

複雑なURIの構文

以下はより複雑になったURIの構文の例である。

  • URIスキーム : http
  • ユーザ情報 : ID:PW
  • ホスト名 : example.com
  • ポート番号 : 8000
  • パス : /hoge/fuga
  • クエリパラメータ : ?name=ryo&a=a
  • URIフラグメント : #n10
ユーザ情報

リソースにアクセスするための情報

ポート番号

ホストにアクセスする際に利用するプロトコルTCPポート番号。省略した場合、HTTPのデフォルト値である「80」が利用される。

クエリパラメータ

動的にページや数値を生成する場合に使用。複数の値を受け渡しする場合は「&」で結合される。

URIフラグメント

URIで指定されたリソースの中でも更に細かい場所の指定を行う(目次等で使用される)

絶対URIと相対URI

OSのファイルシステムにおいては、毎回絶対URIを記述するのは冗長であるため、相対URIが用いられる。

ベースURI

上記の「相対URI」は、サーバー側のディレクトリ構造や現在位置を知らないクライアントからすると、どのファイルを指定しているのかが分からない。

そのため、起点となるベースURIが必要になってくる。ベースURIを用意することによって、以下のように相対URIを絶対URIと同じように取り扱うことが出来る。

ベースURI : [http://example.com/foo/bar/]

相対URI 絶対URI
hoge http://example.com/foo/bar/hoge
hoge/fuga http://example.com/foo/bar/hoge/fuga
./hoge http://example.com/foo/bar/hoge
../hoge http://example.com/foo/hoge

ベースURIの指定方法

  1. 相対URIが出現するページ(リソース)のURIをベースにする

相対URIのリンクが発生するページを起点として、他のURIにアクセスする方式である。

この方式の場合、直感的で分かりやすい(全てのリンクが、現在位置から見た位置を指定しているため)というメリットがある。 その一方、ベースURIをクライアント側で保存しなければならない、ベースURIを見失ったとき、相対URIのみではアクセスできなくなってしまう(可用性の低下)といったデメリットもつきまとう。

  1. 予め明示的にベースURIを指定する

HTMLやXMLのリソース内に予めベースURIを指定する文を組み込む方式

例:HTML この場合、baseタグが指定されたHTML文書(index.html)内のベースURIは「http://example.com/foo/bar」となる

<head>
    <base href="http://example.com/foo/bar"/>
</head>

例:XML この場合、スペースA内のベースURIは「http://example.com/foo」、スペースB内は「http://example.com/foo/bar」となる

<foo xml:base="http://example.com/foo">
    <!--スペースA-->
    <bar xml:base="http://example.com/foo/bar">
    <!--スペースB-->
    </bar>
    <!--スペースA-->
</foo>

この方式の場合、クライアント側にベースURIを保存する必要が無くなり、より確実に相対URIにアクセス出来るようになる。

URIと文字

URIで直接使用できる文字はASCIIのみであり、そのままでは日本語は使用できない。 使用する場合は、%エンコーディングが必要になる。

エンコード

http://example.com<あ

エンコード

http://example.com/%E3%81%82

UTF-8において、「あ」は「0xE3 0x81 0x82」の3バイトから成り立っているため、このような結果になった。 尚、記号「%」は%エンコーディングを示す特別な記号であるため、URIに直接使用することはできない。万が一使用する場合は、「%25」と示す必要がある。

URIの長さ制限について

仕様上では、URIの長さについて特に制限は無い。しかし、実装する際に事実上の制限は存在する。 特にInternet Explorerにおいては2048バイトまでという制限があり、これに合わせて実装されることが多い。

URIの実装で気をつけること

URIの仕様上、取扱に気をつけるべきなのは「相対URI」と「%エンコーディング」の2点である。

相対URI

  • クライアント側で解決しようとすると処理が面倒になるため、WebサービスAPIにおいてはなるべく「絶対URI」を使った方が親切

%エンコーディング

第6章 URIの設計

Webではサービスの終了やURIの変更によって、これまでアクセス出来ていたページが表示できなくなってしまうことがある。 但しURIの変更については、システム設計段階である程度防ぐことは出来るため、以下のような取り組みが必要である。

URIを変わりにくくするための方法

  • URIプログラミング言語依存の拡張子を使用しない (.pl、.rbなど)
  • URI実装依存のパス名を使用しない(cgi-bin、sevletなど)
  • URIに言語のメソッドを利用しない
  • URIにセッションIDを含めない
  • URIはリソースを表現する名詞である

URIを強く意識する

URIは、Webアプリケーションフレームワークが隠蔽をし、あまり意識しなくてもよい存在になってしまいがちだが、以下の点でとても重要である。

  • URIはリソースの名前である
  • URIは寿命が長い
  • URIはブラウザがアドレス欄に表示する

これらの点からURIはWebアプリケーションの中で最も重要するべきパーツであると言える。

※参考

・Webを支える技術 https://www.amazon.co.jp/dp/4774142042/ref=cm_sw_em_r_mt_dp_U_LiIUEbQ3NJSJH

IEURI長さ制限について https://support.microsoft.com/ja-jp/help/208427/maximum-url-length-is-2-083-characters-in-internet-explorer