ハイパーメディアって何？！
あなたがRESTアーキテクチャスタイルについて聞いたことがあるのなら、最も重要な制約について考慮すべきことについても聞いたことがあるでしょう。それは、統一インターフェース、特にリソース上で呼び出されるメソッドを制約するインターフェースの側面についてです。しかし、それ以上に統一インターフェースにとってとても重要なことがあります。特に、「アプリケーションの状態からなるエンジンとしてのハイパーメディア」という扱いにくい名前による制約があります。そして、私たちがそれらを知っているように、それがひとえにRESTfulシステムの「形」の大半を提供しているという意味で、間違いなく RESTの最も重要な制約であると言えます。
本稿では、この制約に関して深く踏んで、それが何を意味しているかを理解しその真価を理解したいと思います。
定義
残念なことに、REST の論文(source)は、実際に見えるものの説明に加えて、その名前に与えられたものを超えて制約を拡張していません。
モデルアプリケーションは、現在の表現の集合の中で代わりとなる状態遷移をチェックし選択することにより、ある状態から次の状態へ移るという意味でエンジンであると言えます。
私の考えでは、それが私たちに役立つ説明を与えているのであれば、制約のスコープを本当に理解する助けとなっていないと思います。したがって、厳密に何が許されて、何が許されないのか。そこから始めるために、制約自身の名前からどんな情報を得ることができるのかということについて見ることは、価値のあることだと思います。
「アプリケーションの状態」とは、「どこで」ユーザーがタスクを完了するプロセスにあるかを決定する状態を言います。例えば、個人で銀行取引をするとき、顧客は口座残高を見て、請求書の支払い用紙に記入しますか？あるいは、新しい小切手を発行しようとしますか？それらは、それぞれが異なるアプリケーション状態です。一部の人は、この「状態」のことをリソースの状態だと誤解している人がいます。それは、この例で言えば、口座の残高や最近の支払いリストとなるでしょう。しかし、それは正しくありません。
アプリケーションの状態は、「セッションの状態」という名でも知られ、RESTの「ステートレス」な制約によって表される状態の一つでもあります。そして、それはクライアントが単独で保持する必要があります。対照的に、VNCやWindowsのリモートデスクトップといったリモートセッション技術を使用しているならば、アプリケーションの状態はサーバー上で完全に保持されます。
「ハイパーメディア」という言葉は、「ハイパーテキスト」(彼の発案です)を一般化するものとして1962年にTed Nelson氏によって発案されました。ハイパーテキストがテキストドキュメントのリンクを含んでいるのに対し、ハイパーメディアは、その範囲を全てのメディア形式に拡張しました。当然、両者の主要ポイントは、私たちが使用する内容にリンクが埋め込まれているということです。
制約の実例
REST は、2003/2004年にインターネット関連サービスで働いている開発者とともにある程度の牽引が始まりました(少なくとも、実際に、「REST」という名前とサービスを結び付けている人たちによって)。目に見えてはっきりしていた2つのものとして、自称「REST API」の Flickr (サイト・英語) と Amazon (サイト・英語) があります。興味深いことに、両者のサービスは、SOAPベースのインターフェースも同時に提供していました。しかし、「REST API」と比較して多く利用されること(source)はありませんでした(source)。その結果、RESTコミュニティはこれらのサービスを受け入れ、それらをWeb上でRESTスタイルを利用する価値と魅力をより明らかにするための手段として利用しました。残念なことに、これらのAPIに関する問題がありました。それらは、(少なくとも)RESTの制約の一つを無視していたので、完全なRESTfulでは無かったのです。実際、Flickr API(Amazon、del.icio.us、なども同様)には、私たちがここでカバーするものよりも多くの問題があったので、ここではハイパーメディアに関する問題にだけこだわりたいと思います。
幸運にも、私たちはこれらの問題を遠くまで探す必要はありません。以下では、自身がコンタクトしたリストを取得するのに使用する"flickr.contacts.getList"(source)オペレーションから返されるサンプルデータを例にとります。
realname="Eric Costello"
friend="1" family="0" ignored="1" />
realname="Ben Cerveny"
friend="0" family="0" ignored="0" />
realname="Cal Henderson"
friend="1" family="1" ignored="0" />
ここで、それら3つの例では、「nsid」属性が特定のコンタクトのためのユニークな識別子を持っています。しかし、一度クライアントがドキュメントを取得するとどうでしょうか? Cal Hendersonについてもっと知りたいときはどうでしょうか? Flickr APIをすぐにチェックしてみると、nsid をパラメーターにとりnsid 文字列によって特定される人に関するより詳細な情報を返す、"flickr.people.getInfo" (source) というオペレーションが公開されています。Calに関してより多くのことを知るためのHTTP GETメッセージを利用することができるURIは、以下のようになります。
http://api.flickr.com/services/rest/?method=flickr.people.getInfo?auth_key=xxxx&user_id=41578656547@N01
これは、ハイパーメディアでありません。ハイパーメディアソリューションは、独自のものではなく標準化された識別子を使います。それは、Webにおける URIです。そうすることで、人のリストのドキュメントから作業したり、それらの一人に関するドキュメントのためのFlickr独自のクライアントの知識が不要になります。標準化された識別子を使用すれば、上記のドキュメントは次のようになるでしょう。
realname="Eric Costello"
friend="1" family="0" ignored="1" />
realname="Ben Cerveny"
friend="0" family="0" ignored="0" />
realname="Cal Henderson"
friend="1" family="1" ignored="0" />
さて、ハイパーメディアに変更することで、それやそれを利用するユーザーにどんなメリットがあるのでしょうか?
Flickr の現在のアプローチは、あるアプリケーションの状態から別の状態へと移るために必要となるFlickr独自の知識をクライアントが必要とするものです。別の言い方をすれば、単に独自仕様のアプリケーションモデルであるとも言えます。独自仕様であるばかりでなく、FlickrのAPI自身が一貫性のあるモデルではありません。(先に述べた)コンタクトの一つに関する情報のためのコンタクトリストを得るために必要な知識に対して、写真のコンタクトリストを得るために必要な知識は異なります(それは、"flickr.photos.getContactsPublicPhotos")(source) 。このことは、Flickrに対する発展性の問題を示しています。即ち、単純なAPIの拡張でさえもそれを広めるには新しい知識が必要になる、言い換えれば、クライアントコードの変更が必要になるということです。検索エンジンをメンテナンスする人が、Flickrのソフトウェアを毎回アップグレードすることに対しほとんど関心がないとすれば、検索エンジンのような一般的なクライアントは、このAPIを経由してFlickrの内容をインデックス化することができないでしょう(あるいは、拡張された APIのアプリケーションモデルを利用する人であれば誰でも同様のことが言えます)。さらに、これはハイパーメディアに特有のことではありません。全ての標準化されたアプリケーションモデルは、同じ利益を提供します。もちろん、それらを利用する人たちが、自身が行っていることを理解していなかったとしても、ハイパーメディア自体はとても人気のあることは実証されていますが。
したがって、共通のアプリケーションモデルを利用するには、単に標準化されているだけでなく、いつまでも不変であるべきです。そして、それぞれが他と独立して発展することを許容することで、利用者と提供者の間の結合を減らすことができます。そうすることで、新旧のサービスがコンポジットアプリケーションへ一緒に結合されることができ、新旧のクライアントも結合することができます。私は、私たちのWebの利用において、過去に書かれたページのドキュメントに簡単にリンクを含めることができたり、そのコンテンツの利用者が新しいバージョンのブラウザをダウンロードする必要なく、それらをシームレスに操作することができることが当然のことだと考えているのだと思います。しかしそれは、偶然のことではなく、意図的なものなのです。
また、Webがハイパーメディアの使用を独占しているという訳ではないということに注意する必要があります。私たちがインターネット上で毎日使用しているもう一つの広く普及したアプリケーションがあります。それは、Eメールです。全てのEメールメッセージは、差出人と受信者に対するEメールアドレスを送るためのヘッダーがあります。そして、それらを一つ以上所有しているということは、別のEメールメッセージを送信するのに十分な情報です。
私たちは、ほとんど知られていない事実について議論しているので、Web自体の重要な側面としてハイパーメディアを使用しないということについて知ることにも興味があるのかもしれません。それは、robots.txt (source)、通称ロボット排除です。それを機能させる方法は、自身のコンテンツを検索エンジンによるインデックス化から除外したいと思うサイトに対し、単に、インデックス化しないことを記述し、"/robots.txt" のURIでファイルを配置するだけです。しかし問題となるのが、私が知る限り"robots.txtファイルに関連する人がほとんどいない" (source) ということです。何故でしょうか? "/robots.txt"は、特に検索エンジンにとっては、固定されていてよく知られた場所にあります。どんなURIでも与えてください。そのドメインに対し対応するrobots.txt URIを構築することができるのです。リンクが別のページで動的に発見されることがないので、これはハイパーメディアではありませんが、検索エンジンによって先験的に知られています。これがよくないソリューションであるとは言っていません。何故なら、ハイパーメディアのアプローチは、2つのネットワークのやりとり(一つはrobots.txtにリンクしたページを見つけること、もう一つはそれを捉えること)があり、それは関係するもの全てに対して負担となるからです。つまり、これがハイパーメディアのコストの良い例です。心にとめておいてほしいのは、本当にベストなアプローチというのはほとんど無いということです。Sitemaps(サイト・英語)は、robots.txtと同じ理由によるものかもしれません。しかし、"favicon.ico"(source) や、iPhone のWebクリップ機能(サイト・英語) などに関しては、ハイパーメディアの利用により多少の利益を得たように思います。例えば、それらのアイコンが、検索エンジンの更新をすることなく、イメージ検索エンジンによってピックアップされるでしょう。
ハイパーメディアを考える際に注目に値するその他の技術として、WADL(Web Application Description Language)(サイト・英語)があります。自称、「RESTful な記述言語」ですが、重要な警告事項があります。WADLファイルの以下の例を見てください。:
このファイルは、"myservices"のコレクションの一部として、"search"リソースを宣言しています。それは、HTTP GETの利用と"query"パラメータの宣言によって、クライアントがURIに指定した入力文字列を与える方法を定義しています。
一見、これは完全なRESTfulでハイパーメディアベースのソリューションに見えます。そして、HTMLフォーム(もしくは URIテンプレート(source) )の使用方法にとてもよく似ています。では、警告すべき点は何でしょうか? それは、WADLが利用されるタイミングの問題です。Webベースのソリューションに関心のある一部のWebサービス提唱者は、設計時の成果物としてWSDL(source)を使用していたようにWADLを使用しています。WADLをこのような方法で使用することは、組み込まれた知識でWebブラウザを開発することに似ています。そう、Googleホームページのフォームがあるときには、ブラウザはコンパイルされています。つまり、もしGoogleが、ブラウザがリリースされた後で後方互換性の無い形(即ち、単純にオプションパラメータを追加しない)でフォームを変更した場合、そのブラウザではリソース/サービスを利用することはできません。WADLでハイパーメディアの制約を使用することは、クライアントが実行時にWADLを利用しなければならないということを意味しています。したがって、あなたの手助けとなるであろうツール(source)としてWADLツールを選択する際は注意してください。
結論
願わくば、ハイパーメディア制約の価値について、思っていたよりも明らかになっていれば幸いです。それ以外にも、私が本当に望むことは、あなたがRESTを使用すると決めたときに、どんなことに注意すべきなのかについての理解がより深まったのであれば幸いです。
ハイパーメディアは、統一インターフェースの制約の一つであることを心に留めて置いてください。したがって、次のより一般的なリトマス試験が適用できるでしょう。もしあなたが、全てのリソース(もしくは、クライアントリソースを要求するサーバーサイドの「API」)について当てはまるわけではない想定でクライアント側のコードを開発するのならば、統一インターフェースを使用しているとは言えません。
著者について
Mark Baker(source)は、SOAとWebサービスのコミュニティで有名です。何故なら、REST(REpresentational State Transfer)というアーキテクチャスタイルを促進するために、継続的な努力をしていて、Webの成功を維持し続けることを意識していない多くの標準や仕様を批判しているからです。
原文はこちらです：http://www.infoq.com/articles/mark-baker-hypermedia