BT

REST "転向" 日記

| 作者: Boris Lublinsky フォローする 0 人のフォロワー , 翻訳者 吉田 英人 フォローする 0 人のフォロワー 投稿日 2011年7月31日. 推定読書時間: 4 分 |

原文(投稿日:2011/07/19)へのリンク

RESTはもう終わりだ,という議論が始まりそうな今になって,REST に関連する書籍 に新たな波が始まっているようだ。Mark Little 氏の 見るところでは

単に REST という単語の解釈が,意見の食い違いを引き起こしていると考えてよいでしょう ...

このトレンドに乗った Ronald Schmelzer 氏の新しい 記事 には,氏が Web サービスから REST に移行した理由と方法が述べられている。

Schmelzer 氏,そして氏の会社である ZapThink によれば,

Representational State Transfer,いわゆる REST は分散ソフトウェアアーキテクチャのひとつの形式で,システム間通信の手段として一般的に採用されている XML ベースの Web サービスの代替となるものです ... あるサービスの要件が確定したとき,それを実装する段階で私はひとつの選択に直面しました ... サービスの通信方法に Web サービスを使用するか,あるいは REST ベースにするか,という選択です。私の例においては,次に説明するような理由で,REST が適切なのは明らかでした。

この文章そのものが興味深い。Dhananjay Nene 氏の過去の 記事 に真っ向から対立しているからだ。

サービス指向は REST に不可欠なものでも,REST の目的でもありません。REST だけがサービス指向ではありません,サービス指向と REST とは無関係なのです ... REST の目的はサービス指向ではありません。REST ではプロセスを,実行するタスクのシーケンスではなく,変更されるリソースのシーケンスとして見ています。別の表現をするなら,REST におけるプロセスとはリソース (より具体的に言うならドキュメント) をやりとりするアクタの集合であり,それらがリソース受信をベースとしてアクティビティを実行する,と言っていいでしょう。

要するに Schmelzer 氏が取り上げているのは実は REST ではなく,いわゆる REST Web サービスと呼ばれるもの – REST 技術を利用した SOA の構築アプローチなのだと考えられる。このアプローチは一般には REST として認識されているが,実は REST とは何の関係もなく,POX (plain old XML over HTTP) とほとんど変わらない。違いと言えるものは,JavaScript Object Notation (JSON) や ATOM,バイナリBLOB など他のデータマーシャリングも複数サポートする,あるいは通常 GET や PUT をベースとしている POX に対して,いくつか付加的な HTTP メソッドを活用する,といった程度だ。

Schmelzer 氏はさらに続ける。

... REST の採用を決定した理由はたくさんありますが,もっとも大きな理由はそのシンプルさです ... REST はWeb サービスより利用や理解が容易です。この容易さ,簡単さが REST を使う理由なのです ... さらにはそれが,広く利用されている Web API のほとんどが REST ベースである理由です ... しかしシンプルさ以上に,私は REST アプローチのエレガンスさを高く評価します。Web の持つ基本的な操作性の良さとスケール性は,そのベースとなっている REST アプローチの前提を証明しています。HTTP オペレーションは標準化されていますし,広く受け入れられ,十分に理解されていて,継続的に利用可能です ...

代表的な REST の利点については,REST に関するどの出版物にも紹介されている。しかし ZapThink のように評価の高いアナリスト企業ならば,さらに詳細な情報が期待できる。

アーキテクチャ上の問題に戻ると,Schmelzer 氏は次のように書いている。

では SOA の基本信条を REST ベースの実装アプローチに取り込むには,どうすればよいのでしょう? ... REST はアーキテクチャ上の形式なのであって,実装形式ではありません。しかも Web や HTTP プロトコルを利用するというのは,その形式における設計上の判断のひとつに過ぎないのです。

残念ながら氏は,この問いに答えてはいない。これに続いて XMPP プロトコルの利用を取り上げているが,実際に2つのアーキテクチャ形式 – ROA と SOA – を同居させる方法については説明していないのだ。

氏は次のような言葉で,記事を締めくくる。

REST や Web サービスは,競技的なスタンスから採用するものでは決してありません。しかし過去10年ほどの間,独断的なベンダや開発者,あるいはエンタープライズアーキテクトなどは,SOA を適切に行うには Web サービスの利用が不可欠である,という考えを拡張し続けてきました ... 実際には SOA は Web サービスを使用しなくても,十分に機能するものなのです。SOA を話題にするというのは,アーキテクチャを話題にすることです – この10年間に私たちが議論してきた,REST あるいは Web サービスを使って実装したすべてのサービスには,それがどのようなプロトコル,インフラストラクチャ,あるいはデータスキーマ上のものであっても,このことが一様に当てはまります。優秀なエンタープライズアーキテクトは,アーキテクチャレベルの抽象度で仕事をします。実装の詳細については,SOA の原則をどのように実践するのか,ということに関心を持つ人たちに任せるのです。

かくして REST が Web サービスより優れている,という議論は続くのだが,真の REST が SOA の基盤と見なされるべきだ,という確証はいまだ存在していない。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT