URI

目的

Web上に置かれた情報(資源、リソース)に、プログラムから簡単にアクセスできるようにするには?

→資源各々に、プログラムで処理しやすい「名前」をつけよう

URI (Uniform Resource Identifier)

• インターネット上のリソースの「名前」（識別子, identifier）

  • インターネット上のリソースのURIは、すべてインターネット上で一意に定まる。

  • URL (Uniform Resource Locator) と URN (Uniform Resouce Name) の総称

    • URN : ドメイン名とは独立にリソースにIDを振る方法

      • 例: urn:isbn:9784774142043

      • 現代のWebではほとんど使われない（URI = URL と思ってほぼ差し支えない）

  • 現在のインターネットでは、URL（Uniform Resource Locator）とほぼ同義であると考えて良い。

  • URIはWebで主に使われているが、Webに限った考え方ではない。Web以外の通信でも使うことができるし、パソコンやスマートフォンでアプリケーション内部から別のアプリケーションを起動する際にも用いられることがある。

• 例

  • http://www.ietf.org/rfc/rfc2396.txt

  • http://pubinfo.oka-pu.ac.jp/searchApp/viewSyllabus.php?id=1642

  • ftp://ftp.is.co.za/rfc/rfc1808.txt

  • mailto:[e-mail]

  • tel:[phone]

URIの利用例

• ブラウザで表示するページの指定

• HTML中のリンクの指定（例: <a href=”http://www.example.com/”>example.com</a>）

• スマートフォンのアプリ内でURI tel:[phone] にアクセスすると、電話アプリで [phone] に電話をかける。

URIの意義

http://example.com/about/index.htmlというURIを例にして、URIの意義を述べる。

後述するように、このURIは主に以下の3つの部分からなっている。

• URIスキーム: http

• オーソリティ: example.com

• パス: /about/index.html

この例におけるオーソリティは example.com というFQDNである。1章で述べた通り、FQDNはDNSによってただ一つのIPアドレスに対応づけられる。そして、IPアドレスは（TCP/IP通信の制約として）インターネット上で一意に定まる。また、URIスキーム+パスで、当該コンピュータ（この例ではexample.com）上でリソースが一意に定まる。この2点を合わせることにより、URIはインターネット上におけるリソースの一意性を保証しているわけである。

またURIは、リソースにアクセスする手段をコンピュータに容易に解析可能な方法で記述するという側面を持っている。例えばクライアントが上の例で示されたリソースを取得する場合は、オーソリティで示されたサーバに、URIスキームで示されたプロトコルで接続し、パスで示されたリソースを取得すれば良い。つまり、リソースへのアクセスを完全に自動化することができる。ブラウザでリンクをクリックするだけでリンク先のページに遷移することができるのは、まさにこのURIの性質によるものである。

URIの構文

URIはいくつかの構成要素からなっている。詳細な構文はRFC3986に厳密に定められている。

• URIスキーム：URIが利用するプロトコルなど。

  • mailtoやtelなど、以下の構文に従わず、別途構文が定められているURIスキームもある。

• オーソリティ(authority):各資源の名前の一意性を保証する単位。

  • ホスト名：その資源を提供するコンピュータ名。FQDNまたはIPアドレスである場合が多い。

  • ユーザ情報：URIの指し示すリソースにアクセスするのにユーザ認証が必要となる場合、正当なユーザ名とパスワードをURIに含めることができる。

  • ポート番号：URIにアクセスするためのTCPポート番号。

    • URIスキームで指定されたプロトコルのデフォルトポート番号の場合は省略可（例: HTTPなら80番の場合は省略可）

• パス：オーソリティ内での資源の識別子。最も簡単な場合、資源（ファイル）への絶対パスになる。

• クエリパラメータ：検索サービスに対する検索キーワードの指定など、クライアントからサーバに何らかのパラメータを渡したい場合に用いられる。

• URIフラグメント：リソース内部の、さらに細かい部分の指定に用いられる。

例

http://www.ietf.org/rfc/rfc2396.txt

• URIスキーム：http

• オーソリティ：www.ietf.org

• パス：/rfc/rfc2396.txt

foo://bar:[e-mail]:8042/over/there?name=ferret&encoding=utf8#nose

• URIスキーム：foo

• オーソリティ: bar:[e-mail]:8042

  • ユーザ情報：bar:baz （ユーザID: bar, パスワード: baz）

  • ホスト名： example.com

  • ポート番号： 8042

• パス： /over/there

• クエリパラメータ： name=ferret&encoding=utf8

• URIフラグメント： nose

URI構文に関する補足

• URIスキームとそれ以下の部分は :// で区切られる。

• ユーザ情報中のユーザIDとパスワードは : で区切られる。

• ユーザ情報とホスト名は @ で区切られる。

• ホスト名とポート番号は : で区切られる。

• ユーザ情報、ポート番号は省略可。

• パスとクエリパラメータは ? で区切られる。

• クエリパラメータについて

  • 一つのパラメータは「パラメータ名=値」という形式

  • 複数のパラメータを並べる場合は & で区切る。

• URIフラグメントとその前の部分は # で区切られる。

URIと文字

URIには、ASCII文字集合の一部の文字（アルファベット、数字、一部の記号）しか使えない。空白記号や日本語の文字などをURIに含めたい場合は、%エンコーディングという方式を用いて、URIに適した文字列に変換（符号化、encode）しなければならない。%エンコーディングの詳細はRFC3986に書かれているが、簡単に言うと「バイトごとに 0x○○ → %○○ と変換」という処理を行う。例を以下に示す。

• 空白記号（0x40）→ %40

• 「あ」という文字（UTF-8 では 0xE3 0x81 0x82 の3バイトで表現される）→ %E3%81%82

%エンコーディングの結果から容易に符号化前の文字列を逆変換（復号、decode）できることは明らかであろう。このように、通信路の制限から、通信したいデータを送信側で符号化し、受信側で復号するという事例は、Webに限らずあちこちで見ることができる。

なお、%エンコーディングを使わずに、直接URIの中でUnicode文字集合の文字を使えるように拡張した規格（Internationalized Resource Identifier, IRI）もあるが、まだ普及には至っていない。

よりよいURI

Webでは、リソースを一意に指し示す識別子としてURIが使われ、外部からのリンクを含め、すべてのリソースへのアクセスはURIを使って行われる。ということは、ある情報をWebでリソースとして公開した後、そのリソースのURIを変更してしまうと、そのリソースはWeb上では「行方不明」になってしまうことになる。 つまり、究極的には、リソースに対するURIは未来永劫にわたって不変であることが望ましい。Web開発者は、リソースを公開する前に、そのURIの寿命が可能な限り長くなるようにURIを慎重に設計し、またURIの維持管理をすべきなのである。

参考ページ: Cool URIs don’t change (日本語訳: クールなURIは変わらない)

どういうときにURIが変わってしまうのか

ありがちな例をいくつか挙げてみよう。

• サーバ機のリプレースでWebサーバのホスト名が変わってしまった

  • http://server1.example.jp/ → http://server2.example.jp/

• Webサーバ上で、公開しているファイルの名前を変更した

  • http://example.jp/foo.html → http://example.jp/bar.html

• Javaで作られていたWebアプリケーションをRubyで再実装した

  • http://example.jp/servlet/LoginServlet → http://example.jp/login.rb

よりよいURIを設計するには

• 実装依存の情報、時間が経てば変化する可能性のある情報を含めないようにする

  • http://example.jp/ (example.jpという組織がある限り不変)

    • サーバ管理技術で server1, server2 といったサーバ名はURIから隠蔽できる

  • http://example.jp/foo.html (ファイル名を変更してもURIを変えないようにできる)

  • http://example.jp/login (Webアプリケーションの実装言語によらず、ログイン機能があるかぎり不変)

  • http://example.jp/2014/10/16 (2014年10月16日に公開された情報。情報の公開日は時間がたっても不変)

  • http://example.jp/news/latest (最新のニュース)

  • http://twitter.com/kunishi/status/13211 (ユーザkunishiの、ID番号13211のツイート。kunishiがTwitterに登録していて、ツイートを消したりしない限り不変)

• できる限り、URIはリソースをシンプルに表現するように考える

どうしてもURIを変更しなければならないときは

極力、HTTP リダイレクト（古いURIを新しいURIに転送するHTTPの仕組。後述）を使う。