BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース RESTFul APIsにおいてHATEOASを使用する利点

RESTFul APIsにおいてHATEOASを使用する利点

原文(投稿日:2009/4/16)へのリンク

サンマイクロシステム社のCraig McClanahan氏(リンク)は、なぜRESTfulサービス(参考記事)の中で従来のREST APIs(リンク)がアプリケーション状態エンジンとしてのハイパーメディア(HATEOAS)を活用できないか、結論を出した(リンク)。彼はその利点を説明するために彼の最近の著書で、設計(参考記事)に関して記した『Sun Cloud API』(リンク)で例をあげている。

我々はまずサービスはただ一つの有名なURI(発側ユーザがアクセスできる全てのクラウドリソースを表現したり、表現するためのURIリンクを含んだクラウド表現に応答するもの)
に対してのみに行われるという仮定から始めた。全システム(状態変更したものも全て含む)の中にあるその他のURIはすべてこれらの説明で検査され、発見された。

Craig氏はこのように述べている。リソースグラフを通してハイパーメディアガイドクライアントを使用するのは、ちょうど相互的なウェブアプリケーションのようなもので、
それはリソースと接続されたリンクに付帯するハイパーメディアのような関係として表現される。そしてそれはクライアントにリソース表現を効果的にナビゲートするものであり、アプリケーション状態を促進するものである。彼の意見によると、そのような設計の利点は以下の通りである。

  • クライアントコードエラーの減少。 バグの約90%は、サーバのために正確なURIに構築中である。典型的な誤りは、パスセグメントを削除し、誤った指示に置き換えたり、URLエンコードを忘れさせてしまうことである。
  • 無効な状態遷移要求の減少。クラウドAPIからの例によると、『展開』するまではバーチャル・マシンは『開始』することはできない。サーバは、URIがPOSTを経由してそれぞれ状態変更を起動することを理解しているが、状態遷移を目的としたURIのみのバーチャル・マシンリスト表示は、最新の状況により有効になる。
  • 旧クライアントを破壊しない、きめ細かい進化。 常に、あらゆるREST APIクライアントが、システムが何ができるのかを色々仮定されながらプログラムされる。しかし、もし『知り得た表現の解釈のみに注意を払う』という制限を記録したり、サーバサイドに直前の動作を中断しないという事を後から追加させたりすれば、すぐに全てのクライアントを破壊せずにAPIを展開したり、サーバ上で同時に複数のAPIをサポートできるだろう。

Marc Hadley氏(リンク)は投稿メッセージの中で、WADL(リンク)がURIとURIテンプレートのセットを表現するために用いられる(参考記事)という以下のアイデアをこの議論に追加した。

WADLがURIとURIテンプレートのセットを表現するために用いられ、URIが必要なリソースにアクセスできるように構築するためにクライアントに依存し、クラウドAPIが一つの『root』URIを表現すること、その表現の中で追加URLを見つけるために文書化して、それをクライアントがサービスを超えて使用することができるということ。

彼はどのようにウェブアプリケーションをサンクラウドAPI(リンク)のようにWADL(リンク)を使って文書化できるか述べ、次に例をあげて彼のアイデアを説明している。

  1. 各リソースを説明する為にリソースタイプを用いる。
  2. 組み込まれたリンクを識別するために表現をパラメータ化する。
  3. それぞれ組み込まれたリンクを識別したリソースタイプを定義する。

オリジナルの投稿メッセージ(リンク)を確認してください。また引き続きディスカッショングループ(リンク)において論議可能です。

この記事に星をつける

おすすめ度
スタイル

BT