code up

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

HATEOASとは

REST関連のJava実装を色々調べるにあたってよく出てくる言葉HATEOASというのがよく分からなかったので、HATEOAS - Wikipedia, the free encyclopediaを読んでみた。そして、せっかくなので翻訳した。

最初はSaaSみたいな~ as ~という呼び方に便乗した、ロハス(LOHAS)とかエコシステムみたいな実体のよく分からないバズワードなのかと思ってたけど、ちゃんとした意味があるようだ。

RESTのJava実装(JAX-RS)はまだ使ったことがなくこれから使うのだけど、JAX-RS (Java API for RESTful Web Services) API 2.0においてクライアントAPIというパッケージが追加となり、HATEOASの原則を実装したというので私が担当しているプロジェクトにおいて理解しておく必要があるのか実践した方が良いことなのかそうでないのか、という事を知りたかった。

結論としてはまだHATEOASの制約を理解/実践する必要ないと思った。私みたいなサーバー側業務アプリケーションを作る人向けの話ではなく、どちらかというとクライアント側のライブラリを作るような方々への提案だと思った。とあるデータを取得する時にメディアタイプ毎にクライアントが自動的に動作したら、サーバーとクライアントがより疎結合になって、お互い楽になりますよねって感じだけど、今実践したとしてもクライアント側に負荷をかけるだけ・・・かなーーと。

あまり直接的な翻訳にはしてないので間違いがあったらごめんなさい。論文本体やFielding氏のブログも読んでないことに加え、HATEOAS/RESTを勉強中の身で訳しているので行間の解釈とか間違っているかもです。

[]の部分は本文にはない補足っぽいもの。

HATEOAS

HATEOAS, Hypermedia as the Engine of Application State[アプリケーションの状態(今ユーザーが何をしているか)を動かす力としてのハイパーメディア]の略, とは、他のネットワークアプリケーションと区別するためのRESTアプリケーションアーキテクチャの制約のひとつである。その本質は、クライアントがネットワークアプリケーションと対話する際、全ての対話はアプリケーションサーバーによって動的に生成されるハイパーメディア[リッチテキスト、動画、音声、リンク等]を通して行われているということである。RESTクライアントはいかなる特定のアプリケーションやハイパーメディアの一般理解を超えるサーバーとどう対話するのかといった予備知識を必要としない。例えばサービス指向アーキテクチャ(SOA)と比較してみると、それらのクライアントとサーバーはドキュメントやインターフェース記述言語(IDL)によって共有された決められたインタフェースを通して対話している。

HATEOASの制約はサーバーが独自に機能を発展できる方法でクライアントとサーバーを分離することに寄与している。

詳細

RESTクライアントはシンプルな固定URLを通してRESTアプリケーションを利用する。クライアントが取るであろう次の行動はサーバーから応答されるリソース表現(representations)の中に必ず見出すことができる。これらの表現で利用される、そしてリンクの関連(Link relation)[HTMLにおけるlinkタグのrel属性やaタグ, areaタグ]に含まれるであろうメディアタイプ[image/jpeg等]というものは標準化されている。表現の中にあるリンクを選択することによって、あるいはそのメディアタイプによってもたらされる他の方法を使ってその表現を操作することにより変化するアプリケーションの状態を通してクライアントは遷移する。このようにRESTfulな対話とは、外部の情報(out-of-band information)によってではなくハイパーメディアによって動作する。

クライアントはサーバーによって提供される全てのメディアタイプと通信構造を解釈する必要はない、というのはこの解釈というのはサーバーによってクライアントに提供される"code-on-demand"[Java Applet, Flash, JavaScript等のコード]を通じてリアルタイムに(on the fly)補完されることがあるからである。

起源

HATEOASの制約はRoy Fielding氏の博士論文によって定義されたRESTに含まれる特徴"uniform interface"[HTTPメソッド + リソース名 = uniform interface]内の主要な部分である。Fielding氏は彼のブログでその構想について更なる説明を加えている。

Fielding氏は、HATEOAS制約やその他のREST制約が厳密であることの理由について次のように説明している。"数十年拡張可能なソフトウェアデザイン: 全ての細かい仕様はソフトウェアの寿命や独自の進化を助成することである。多くのこれらの制約は短期的な効果とは正反対の位置にある。残念ながら人間とは短期的な設計が得意であり、たいてい長期的な設計を苦手とするものである。"

関連記事
タグ:HATEOAS Wikipedia
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。