読者です 読者をやめる 読者になる 読者になる

uehaj's blog

Grな日々 - GroovyとかGrailsとかElmとかRustとかHaskellとかFregeとかJavaとか -

HATEOASって何だ?

hateoas rest restful grails

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を介して、クライアントとサーバのより明確な構造的分離が達成できる

んで、来るべきGrails 2.3ではHATEOASなアプリを簡単に書けるようになるよ、と。
しかし、なんて読むんだろう。ハテオアス?

Web API: The Good Parts
Web API: The Good Parts
posted with amazlet at 16.05.19
水野 貴明
オライリージャパン
売り上げランキング: 38,557

広告を非表示にする