前回，REST（REpresentational State Transfer）アーキテクチャ・スタイルに準拠した，新しい軽量なWebサービスが増えてきたことについて触れました。アーキテクチャ・スタイルとは，情報システムのプロトコルやデータ構造（情報構造）の基本的性質を規定する“制約の束”のようなものです。今回は，このRESTについてもう少し説明しましょう。

　RESTを既定する制約を挙げると以下のようになります。

(1)クライアント/サーバー型
(2)ステートレス（Stateless）
(3)キャッシュを許可
(4)統一インターフェース（Uniform Interface）
(5)階層化システム（Layered System）
(6)コード・オン・デマンド（Code-on-Demand）

　(1)は，WebブラウザとWebサーバーで構成される，クライアント/サーバー型のネットワーク・アーキテクチャ・スタイルを採用することを指します。WebブラウザとWebサーバー，つまりユーザー・インターフェースとデータの格納場所を分離することで，サーバーを単純化できるなどのメリットが得られます。

　(2)は，サーバー側でセッションの状態を管理せず，処理に必要なすべての情報をリクエストに持たせるようにする，という制約です。クライアント/サーバー間のやりとりを単純化できるのがメリットです。(3)は，「キャッシュ可能」という印が付いたレスポンスについては，クライアントがキャッシュを保持しても原則問題が生じないようにすることを指します。クライアントがレスポンスをキャッシュすることで，トラフィックを削減できます。

　(4)はクライアント/サーバー間のインターフェース（GET，POST…）を統一すること。(5)はシステムを複数の階層に分割し，隣接する層以外への依存関係を持たないようにすることです。プロキシなどを配置できるのはこのおかげです。(6)はオプショナルですが，クライアント側でコードをダウンロードして実行する仕組みを指します。JavaScriptやFlashなどを実行する仕組みをイメージしてください。

　以上，(1)から(6)へと順に制約を追加していくことで，常にURIを介して情報をやりとりするという，おなじみのWebらしい仕組みが出来上がることが分かるでしょう。処理のコンテキストに依存して記述を省略したり，特定のクライアントとサーバー間で独自の取り決めをしたりといったことはありません。

　なお，上記のように制約を付加していった経緯は，Roy Fielding氏の博士論文に掲載された図にまとめられています。右下のRESTに向かって，上記の制約群が少しずつ追加されているのを確認できます。

REST＝Web 2.0ではない

　ところで，ここまで読んで「それなら，なぜRESTがWeb 2.0なの？ Webって元々RESTだったんでしょ？」という疑問を抱かれた方も多いのではないでしょうか。その通りです。RESTは，Webの生みの親であるTim Berners Leeが考えた仕組みの“筋の良さ”を，10年遅れで理論的に根拠付けただけ，と言っても過言ではありません。実際，SOAP/WSDLベースのWebサービスなど一部を除けば，RESTに“極力”準拠しようと参加者が歩み寄り続けたために，仕様の複雑化が回避され，Webが隆盛をみたわけです。

　このITproのサイトも典型的なWebのリソースとなっています。サーバー側でデータベースから動的にページを生成しているかどうかは別として，少なくともクライアント側からは各記事が固定したURIを持っているように見えます。このため，URIを指定するだけでリソースを再利用できるのです。

　若干私見が入りますが，RESTであればWeb 2.0だ，というのは誤りだと思います。REST準拠だからといって，Web 2.0にはなりません。せいぜい本来のWebらしいWeb，と言えるだけでしょう。言い換えれば，Web 2.0はWebの原点に帰ろう！という技術思想だ，と言えるのではないでしょうか。

　では，ネットワーク・インフラとしてのWeb 2.0とは何なのでしょうか。プラットフォームとしてのWebがメジャー・バージョンアップするとしたら，どんな要件が必要で，何がWeb 1.0との差分として新しく加わるべきなのでしょうか。

　一つには，ブログで有効性が実証された時系列の構造を，W3Cの勧告，もしくはそれに類する規格で標準化したものが期待されているのかもしれません。緯度・経度・高度などの基本的なメタデータを取り込んだ，地理的構造の標準化がそれに続くのでしょうか。とはいえ，組織図や家系図など，論理的な位置情報にも様々ありますし，将来，全く新しい論理的な位置情報だって出現する可能性があります。むしろこれらを統一的に規定する，メタな仕組みが該当するのかもしれません。

　リソースへのアクセス履歴の記録方法の統一や，その活用法の標準化はどうでしょうか。これらは言い換えれば「動的なメタデータ」です。Mixiの足跡機能（誰が閲覧したのかを記録する機能）により，コミュニティ活性化の手段の一つとして有効性が既に実証されているとも言えます。ただ，Webインフラの標準化としては，もう少しメタな規格統一が求められるような気がしますが…。

　次回は，RESTタイプのWebサービスと伝統的なWebサービスの使い分けについて取り上げる予定です。