2013-06-28

Grails 2.3のRest機能のドキュメントを読んでいたら、拡張の一つとして「8.1.7 Hypermedia as the Engine of Application State」というのが書いてあって、調べると面白かったので、この資料(REST: From GET to HATEOAS)を読んだだけでの、私の理解する限りのメモを記しておきます。

一言でいうと、HATEOASとは、Restfulパターンを拡張するアーキテクチャパターンで、Restful原則に対する追加的な制約。どういうものかというと、HTMLアプリの画面遷移を抽象化した、状態遷移を表現するRestful API(=Restful WebアプリのWebインターフェース)を設計するための具体的な方法論になってる。

もちろんGrailsに特化したものではなく、Restと同じレベルのWebアプリケーション一般概念でありRestを拡張する。すでにサポートするライブラリがいくつかあって、Spring FrameworkでもHATEOAS拡張をしている。Grailsのはそれをたぶんラッピングしている。

具体的には、

Restというのは言っても難しいよね
- 単に何かを読み書きする、というアプリならいいかもしれない。GETとPUTとPOSTとDELETEでそれを読み書きする。
でも、一般にWebアプリケーションのサーバサイドというのは、そんなに単純じゃない。
例えばeBayのようなオークションアプリをRestfulアプリとして定義するとしよう。こんな感じ。
- 品物をウォッチリストに入れる
- 売り主の評価をチェック
- 売主の詳細を見る
- 入札する。
これらを、正しい順序で呼び出す必要がある。ステートとそれぞれの選択肢、それらを合わせたフロー構造がありルールがある。これらはどこで定義されるべきか？
- Restfulにせよ何にせよ、本来「Webアプリケーション」が定めるものの一部であるはず。
- HTMLアプリとの比較で言うと、HTMLアプリの画面遷移は、利用者から見たアプリケーションの状態遷移を表現していて、リンクはそれぞれの状態で「何ができるか」を提示していた。
- 同じことをRestでしようとしたとき、それらのステートとフローの構造をクライアントJavaScriptで記述されるアプリ中にハードコーディングで埋没させて定義して良いのだろうか？
- だってそうだと、サーバサイドの独立性というものが無いよね。特定のクライアントと結合しないと動かないなら、Restサーバの利点が損耗する。
そこでHATEOASですよ
- HATEOASでは、
  - まず、基本はRest
  - その上に、上の意味でのアプリの「状態」を表現するXMLないしJSON表現をアプリケーション固有のものとして定義
  - 個々の状態を表現するXML/JSONに、固有のMimeTypeを与える
  - その表現の中に、リンクが含まれている
  - リンクを辿ることが、アプリケーションの状態遷移である。
- この場合、クライアントの役割は、HATEOASなAPIのブラウザになる。
- 結果として状態遷移とフロー構造を外在化・明示化することになる
  - 結果として、Restful APIを介して、クライアントとサーバのより明確な構造的分離が達成できる