ここ数年の間、エンタープライズアプリケーションの構築にRESTfulな手法を採用するのが、無視できないほど人気になった。今やREST 対 WS-*という議論やRESTとSOAのどちらが優れているかという議論から、RESTベースの実装の成熟度へと議論の焦点が移っている。しかし、残念なことにこの分野も混乱と論争と対立が盛なようだ。成熟度とRESTを同じ文章で語るとき、成熟度を計測する手段としてリチャードソン成熟度モデルに言及する人もいる。例えば、Martin Fowler氏は最近の記事でこのモデルで定義されているレベルについて論じている。
- レベル1: アーキテクチャにリソースの概念を導入する。
- レベル2: HTTPの動詞をサポートする。
- レベル3: HATEOAS.
氏曰く、
これ[リチャードソン成熟モデル]は、RESTについて考える良い方法ですがRESTのレベルそのものを定義するわけではありません。[リチャードソン成熟モデルの]レベル3はRESTの前提条件であるのはRoy Fieldingの仕事から明らかです。
氏はモデルを文脈に導入する手助けになるIan Robinson氏とのやり取りに言及して次のように言う。
[Ianは]このモデルにある魅力を強く示しました。[...]それは一般的な設計パターンとの関係です。このモデルを使えば提供したいHTTPサービスについて考えやすくなり、このサービスを使いたいと思っているひとの見通しを明るくします。
- レベル1は分割統治や巨大なサービスのエンドポイントを複数のリソースに分割することで複雑さを扱うことに取り組む段階です。
- レベル2は標準的な動詞を導入して同じような状況を同じように扱い、不必要な多様性を取り除く段階です。
- レベル3は発見しやすさを導入して、自己文書的なプロトコルを提供する段階です。
しかしこのモデルはある程度役に立つものの、RESTコミュニティには意見の相違がある。例えば、この記事では、Roy Fielding氏のRESTfulシステムの構成要素についての議論に言及しながら、次のように書いている。
したがって、Royの厳格な基準によれば、ハイパーメディアはRESTの*前提条件*です。ハイパーメディア以外はRESTを名乗ってはいけません。だから、成熟モデルは次のようになるでしょう。
- レベル1 :RESTではない
- レベル2 :RESTではない
- レベル3 :RESTである
しかし、この記事のコメントで次のような指摘があった。
成熟のレベルについて考えていないのなら、REST(“HTTPの動詞”を“皆が同意できる事前に定義された動詞のセット”に置き換えたいと思いますが)でないものについて考えたことになります。実装の観点から言えば、レベル1を通らないでレベル3にはなりません。なので順番には意味があると思います。
そしてRESTful Web Services Cookbookの著者であるSubbu Allamaraju氏も最近の記事でリチャードソン成熟モデルを使うことについての議論に参入した。氏はこのモデルはアプリケーションのRESTの度合いを計測するには使えないと明言している。氏曰く、
あるアプリケーションが必要な品質を確保するために正しい制約を選んでいるかではなく、RESTの制約にどの程度従っているかを基準にして判断するのは視点が間違っています。品質を問わずにNoSQLを使わずにRDBMSを使っているという理由でアプリケーションを批判するのと同じです。ハイパーテキストの制約に従うことでRESTfulなアプリケーションが"RESTの栄光"を手に入れたと考えるのも同様に愚かなことです。問題なのはその制約がアプリケーションの様々な機能的、非機能的な能力に関わるかどうかなのです。
この記事にはコメントを通して面白いやり取りがあった。例えばMike Amundsen氏は次のように書く。
私もFielding氏のRESTの条件に忠実な実装が自動的に優れた実装であると仮定するのは間違っていると思います。しかし、その実装が(RESTやC2などの)制約にどの程度従っているのか評価するのが“視点が間違ってい”て“愚か”なことであるという考えには同意でいません。[...]あなたはこの記事で何が言いたいのですか。なぜ規則への適合性を評価しないのですか。あなたが重要だと思っている評価には得るものがないのでしょうか。役に立たない評価からなにが得られるのでしょうか。危険で誤解があり役に立たない評価作業の中に埋もれてしまっている思い込みもあるのではないですか。
この続きは氏の興味深いエントリに書いてある。この記事にはアプリケーションRESTful度合いを計測するメリットと最初からRESTを使うことの便利さについて書かれている。
SubbuはMikeの元のコメントに返信をした。
評価を下すには文脈とその文脈が提供する質的な属性がなければなりません。RESTの周りだけを対象にした評価は貧弱で疑問も多い意思決定を導いてしまうかもしれません。[...] 普遍的に正しい条件など存在しないのです。
Mikeはこれに答えて、
私はあなたの観点が分かりました。あなたは、初期段階の実装での振る舞いについて話していますね。“今日Webアプリをビルドした。これが私が従った制約だ(なぜならFieldingがそういっていたからだ等)。”この場合、“制約”との適合性を考えるのは不適切です。あなたの言うように初期段階ではサポートしたいと思っている“機能的、非機能的能力”に注力します。しかし、質的な属性が決まれば、この性質を推し進めるための制約を選択する(Fielding氏がしたように)のは合理的なうやり方だという考えにはあなたも同意してくれると思います。
このコメントの後でIan Robinson氏が議論に参入してきた。氏もリチャードソンのモデルを盲目的に使うのは賢くないと考えいている。
[...] もともとLeonardは開発者がRESTを理解できるように彼の手法を作りました。それだけのことです。彼はより一般的で親しみのあるソフトウエア開発プラクティス(分割統治等)とウェブアプリケーションの技術(あらゆるものにアドレスを与える、表現の転送を制御する目的でHTTPを使う)の間に類推を働かせることで自身の手法を確立したのです。
また、Restfulieの著者であるGuilherme Silveira氏はRichardsonのモデルをRESTアーキテクチャの成熟度を表す5段階のモデルに拡張しようとしている。このモデルはリチャードソンのモデルとは違い、HTTPに縛られない。
- ステップ1: 統一したインターフェイスを取り決める。
- ステップ2: リンクされたデータを使ってクライアントがリソースの状態と関連をたどれるようにする。
- ステップ3: リンクに意味的な"価値"を負荷する。
- ステップ4: create clients "リソースの表現の関連とメディアタイプの解釈だけで動作が決まる"クライアントを作る。
- ステップ5: "必要に応じてクライアントが先が見通せない特定の状況でどう振る舞えばいいのか教えるコード。つまり、新しいメディアタイプの定義。"
この5段階の方が優れているだろうか。元のモデルが使えないと言ったSubbuやその他の人々の関心事も扱っているか。他にもっと良い方法があるだろうか。