REST リソースとは？URI で理解する Web の基本

REST を学ぶには、まず ‘リソース’ の概念を理解する必要があります。
REST の各制約の前に、まずはリソースについて見ていきましょう！！

関連するブログは、以下にあります。
よかったら読んでやってください笑

WEBにおけるリソースの例

• 東京の天気予報

• 技術評論社の「WEBを支える技術」のページ

• 新花巻駅の写真

• 筆者の最近のブックマーク

上記はいずれもリソースです。
WEB上には、他にも多様なリソースが存在します。
リソースを一言で言うと「WEB上に存在する、一意に識別可能なあらゆる情報」です。

図1：抽象化レベルと Web の対応

図1 は Web を「設計思想（REST など）」「仕組み（HTTP／URI など）」「実装（Apache／Chrome など）」の３つに分けています。

リソースを識別する「URI」や「HTTP メソッド」は、この真ん中の“仕組み”層に該当するため、図1 ではアーキテクチャ層に位置づけられます。

リソースが名前を持つ理由

そもそも名前や名詞には、ものを他のものと区別して指し示す役割。
しかし、同姓同名の場合、人間ならあいまいでも区別できるが
プログラムの場合は、区別できません。
名前（URI）で他から重複なく区別できるように指し示すためのものです。

リソースの名前としてのURI

リソースの名前はURIのことです。
先ほどのリソースは、それぞれ次のようなURIで識別します。

• 東京の天気予報

  http://weather.yahoo.com.jp…….
  

• 技術評論社の「WEBを支える技術」のページ

  http://wdpress.gihyo.jp……
  

• 新花巻駅の写真

  http://www.ecn.purdue.edu…….
  

• 筆者の最近のブックマーク

  http://b.hatena.ne.jp/yohei/…….

このようにリソースをURIで表現することで、一意の名前にして情報を区別することで、
アクセスができるようになるってことです。

ここまでのまとめ

• リソースとは、WEB上の情報である。

• 世界中の無数のリソースは、それぞれURIで一意の名前を持つ

• URIを用いることで、プログラムはリソースが表現することで情報を区別でき、アクセスすることができる。

複数のURIを持つリソース

1つのリソースは複数のURIを持つことが可能です。
例えば、もし今日が2010年1月1日だとすると、次の２つのURIは同じリソースを指します。

• http://weather.example.jp/tokyo/today

• http://weather.example.jp/tokyo/2010-01-01

| 意味               | URI                 |
|-------------------|---------------------|
| 今日の東京の天気     | `/tokyo/today`      |
|-------------------|---------------------|
| 2010-01-01 の天気  | `/tokyo/2010-01-01` |

2010年1月1日の時点では、この２つのURIは同じリソースを指しますが、それぞれのURIの意味は異なります。
1つ目の例は、「今日の東京の天気」を示すURIであり、
2つ目の例は「2010年1月1日の東京の天気」を示すURIだからです。

http://weather.example.jp/tokyo/todayは、日付が変われば指し示すリソースが変化します。
リソースに別名のURIをいくつも付けると、クライアントがリソースにアクセスしやすくなります。
その反面、どれが正式なURIなのかがわかりにくくなってしまう欠点も併せ持ちます。

リソースのアドレス可能性

今では当たり前となったWEBのURIですが、これは画期的な発明だったと言われています。 webとURIの発明以前は、大きなファイルをどこかのサーバに置いて、その場所を友人にメールに教える場合、次のような文面を書かなければなりませんでした。

From: yoheu@example.jp
To: inao@example.jp
Subject: Sample File

お疲れ様です。
先日聞かれた例のファイルをftp.example.jpにおきました。 
ディレクトリは/public/dataで、ファイル名はsample_file.gzです。 
このサーバはanonymous FTPなので、匿名ユーザでログインしてください。

見ての通り、とてもめんどくさいです笑
URIがある現在では、特定のファイルの取得方法を詳しく説明する必要がありません。
ftp://example.jp//public/data/sample_file.gzというURIを1行書いてアクセスしてもらうだけで十分です。
また、当時では上記のメールを人間が理解するのは簡単ですが、プログラムで解釈してファイルをダウンロードするのは至難の業なんです。
人間の言葉で書かれたメールからFTPサーバとログイン情報、さらにサーバ内のディレクトリ構造を取り出さなければならないからです。
しかし、URIはこの問題を一気に解決しました。
URIは構造を持っているため、プログラムで簡単に処理できるようになったのです。

このようにきちんと名前がついており適切な手段でアクセスできる状態にすると、プログラムをとても作りやすくなります。

リソースの表現（Representation）と状態（State）

リソースは、「WEB上に存在する情報」という抽象的な概念です。
サーバとクライアントの間で実際にリソースをやり取りするとき、
何らかの具体的なデータを送信し合います。
一つのリソースに複数の表現をを持つことが可能です。

例えば、天気予報のリソースでは、HTML形式ではもちろん、テキスト形式でもPDFでも画像でも表現できるんです。

リソースの複数の表現に個別のURIを与えれるし、HTTPの仕組みを使って
一つのURIで複数の表現を返すことができます。
また、リソースには状態があり
時間の経過に従ってリソースの状態を変化すると、その表現は変化します。
例えば天気予報のリソースなら、現在の予報は「曇り」だが、数時間後には「晴れ」に状態が変化するかもしれません。

まとめ

本記事では、「REST を理解する第一歩」として Web 上のあらゆる情報を表す リソース の概念を整理しました。

• リソースとは一意に識別可能な「情報のかたまり」

• URI によってプログラムから確実にアクセスできる名前を持つ

• 複数の表現（HTML／JSON／画像など）や状態（時間とともに変わるデータ）を取り扱える存在

リソースの扱いがわかると、次は「それらをどのように安全かつ効率的にやり取りするか」という REST の５つの制約 を学ぶ準備が整います。
次回は、REST を特徴づける「クライアント/サーバ」「ステートレス」「キャッシュ可能」「層化システム」「統一インターフェース」「ハイパーメディア」の各制約を順に解説し、リソースを使った API 設計へと踏み込んでいきます。