「Webを支える技術」内容メモ第2部 #HTML

はじめに

前回の続きです。

第4章

URI(Uniform Resource Identifier)について

直訳すると、「統一リソース識別子」
URIを使うことでweb上に存在する全てのリソース(名前を持ったあらゆる情報)を一意に示すことができる

URIの例

http://yohei:pass@blog.example.jp:8000/search?q=test&debug=true#n10

URIスキーム : http
URIの始まりであることを示す
また、そのURIが利用するプロトコルを示すのが一般的
後ろに続く部分は「://」で区切られる
ユーザ情報 : yohei:pass
リソースにアクセスする際のユーザ名とパスワード
間が「：」で区切られる。また、ない場合もある
ホスト名 : blog.example.jp
DNSで名前が解決できるドメイン名かIPアドレスが出現する。
また、インターネット上で必ず一意である
ポート番号 : 8000
ホストにアクセスするときのプロトコルで用いるTCPのポート番号を表す。
ポート番号が省略されている場合は、各プロトコルのデフォルト値が使われる(HTTPの場合、80番)
パス : /search
ディレクトリ階層を表す。ホストの中でリソースを一位に指し示す
クエリパラメータ : q=test&debug=true
「?」が付き、"名前=値"形式のクエリ(処理要求を文字列で表したもの)が続く
複数ある場合、「&」で連結される
1つ以上のクエリの集合を、「クエリパラメータ」と呼ぶ。検索サービスに検索キーワードを渡す時など、クライアントから動的にURIを生成するときに利用する
URIフラグメント : #n10
その前までの文字列で表現するURIが指し示すソース内部の、さらに細かい部分を特定するときに利用する
「#10」の場合、HTMLでid="n10"である要素までページが移動する

URIは「インターネット上で必ず一意になるホスト名の仕組み」と、「ホスト内で必ず一意になる階層的なパスを組み合わせる」ことで、リソースのURIが世界中のどのリソースのURIとも重複しないような仕組みとなっている

絶対URI,相対URI

絶対パス、相対パスとも呼ぶ
以下の例のように、/(ルート)から記述したパスのことを絶対パスと呼ぶ

/foo/bar/baz

例

現在いるディレクトリ -> /foo/bar/

      ↓現在地↓
[foo]--[bar]--[hoge]--[huga]
     ｜
      ∟[hoge]

相対パス　　　　　絶対パス
hoge　　　　　　 /foo/bar/hoge
hoge/huga      /foo/bar/hoge/huga
./hoge　　　　　 /foo/bar/hoge
../　　　　　　　 /foo
../hoge　　　　　/foo/hoge

ベースURI

相対URIは単体ではどの位置にあるのか解釈することができないので、相対URIの起点となるベースURIを指定する必要がある
上記の場合、ベースURIを「http://example.jp/foo/bar」とすると相対URIの意味が理解できるようになる

URIに利用できる文字

アルファベット(A-Za-z) , 数字(0-9) , 記号 - ~ : @ ! $ & ' )(

%エンコーディング

URI使用が許可している文字以外を、URIに入れることができる
http://ja/wikipedia.org/wiki/あ => http://ja/wikipedia.org/wiki/%E3%81%82
(日本語はURIに入れることができないが、%直後につけることでエンコードしてサーバに転送する)

URIの長さ制限

仕様上は存在しないが、実装上は存在する
IEだと2038バイト程度まで

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

相対URI
クライアントで相対URIを理解しようと思ったら、面倒な処理が必要となる
WebサービスやWeb APIを実装する場合は指定がない限りは絶対URIを利用した方がよい
%エンコーディング
URIにエンコードされた文字列が複数並ぶと可読性が低下し、非常に分かりづらい
混乱を避けるため、なるべくUTF-8に対応した文字列を用いた方がよい

第5章

良いURI(クールURI)とは

基本的に「変わらないこと」が好ましい

クールURIを設計するためには

以下の3つを意識する

言語に依存した拡張子やパスを含めない
メソッドやセッションIDを含めない
リソースを表現する名詞であることを心がける

要するに、シンプルであることが大事

URIのユーザビリティ

シンプルなURIは、ユーザビリティ(使いやすさ、使い勝手)も良い

・複雑なURI
http://example.jp/servlet/LoginServlet

・シンプルなURI
http://example.jp/login

シンプルである方が覚えやすく、開発者ではない普通の人にも使いやすい

URIを変更したい場合

リダイレクト(古いURIから新しいURIに転送させること)処理を記載しておくと、ユーザに配慮が利く

URIのテクニック

・拡張子で表現を指定する
「.cgi」「.pl」といった、基本的に実装に依存した拡張子は好ましくない
しかしながら、「日本語か英語かどちらかのページを表示する」といったようなリソースの表現を特定できるような拡張子は、可読性が上がったりと良い作用が起こる

・日本語ページ
http://example.njp/2010/05/01/press.ja

・英語ページ
http://example.njp/2010/05/01/press.en

URIの不透明性

上記のような、言語コードが拡張子でついたページのフランス語版(.fr)のページが欲しい場合
->http://example.njp/2010/05/01/press.frというようなURIではないかと推測できる

しかしながら、用意されているとは限らない
URIをクライアント側で組み立てたり、拡張子からリソースの内容を推測したりすることができないこと = 「URIがクライアントにとって不透明であること」と呼ばれる
設計したクライアントアプリケーションを作る際は不透明性を意識することも大事

終わりに

第2部、URIについてのメモでした。
大変ではありますが、前回同様に文字に起こすことで知識が定着するということはかなり実感できました。

次の第3部はHTTPなんですけど、多分これが一番大変そう・・・

「Webを支える技術」内容メモ 第2部