REST 入門(その9) REST と SOAP

» REST 入門 目次

前回、WWW のうち REST アーキテクチャスタイルに従っていないものについて解説しました。 今回は「その筋」では有名な REST と SOAP の対決の概略を解説します。

Google で "REST vs SOAP" あるいは "SOAP vs REST" を検索すると、 たくさんの Web ページが見つかります。 いろいろな立場の人が、それぞれの意見を述べ合っていて、 ここで全ての主張や意見を解説するのは不可能です。 これから解説する内容は、あくまでも個人の意見ということをご了承ください(まー weblog なんてそんなもんですが)。

ところで最初からこんな話をするのもアレですが、 REST と SOAP は比べられるものなのでしょうか。 REST はこれまで何度も述べてきたとおり、ネットワークシステムのアーキテクチャスタイルです。 一方で SOAP はプロトコル、あるいはメッセージのエンベロープ形式です。 二つを比べようにもあまりに次元が違い過ぎます。 この二つが並べて議論されるとき、たいていは SOAP を拡大意解釈するか、 あるいは REST を縮小解釈しています。 たとえば Amazon Web サービスの SOAP API と REST API を比べたり(REST の縮小解釈)、 あるいは SOA と REST を比べたり(SOAP の拡大解釈)。 これには歴史的理由がいろいろあって、紆余曲折してきているというのが真相です。 ここでは時系列に沿って、REST vs SOAP を振り返ってみたいと思います。

SOAP RPC と REST

2000年ごろ、Web サービスといえば SOAP/WSDL/UDDI でした。 SOAP には何種類かの使い方があるのですが、 このころは SOAP エンコーディングを使った RPC (SOAP-RPC)が主流の使い方でした。 SOAP-RPC がやりたいこと(できること)は非常に単純です。 異なるプラットフォーム同士で RPC をすることです。

プラットフォームが異なる場合、標準的なデータフォーマットが必要となり、そこに SOAP エンコーディングという XML を採用したプログラム言語のデータ構造のシリアライズ形式が使われました。 SOAP エンコーディングを使った RPC は WSDL の記述の仕方から rpc/encoded と呼ばれます。

SOAP-RPC は便利です。それまで RPC がなかなか実現できなかったところで RPC が可能になりました(たとえば UPnP)。 しかし、SOAP-RPC は結局のところ RPC ですから、それ以前の RPC や DCOM, CORBA などの分散オブジェクト技術が持っていた問題をそのまま受け継ぐことになります。 サービスの呼び出し単位は細かく、オブジェクトが状態を持ちがちなので、スケーラビリティが問題になります。 そのような理由から SOAP のトレンドは SOAP-RPC から別のものに移っていくことになります。

WS-*/SOA

rpc/encoded よりも粒度が粗く、RPC でなく XML をそのままメッセージとして送信する、 そんな SOAP のやり取りを document/literal 形式といいます。 これは引数が DOM の Document オブジェクトひとつのメソッドを思い浮かべればいいでしょう。 XML を DOM でそのまま渡して、結果も DOM で返ってくる。 非常に単純化するとそんな形式です。

一方で SOAP の世界には WS-* と呼ばれる仕様群が登場します。 SOAP 自身は前にも述べたとおり単なるメッセージエンベロープ形式であり、 実際の運用ではさまざまな機能をその上に実装する必要があります。 各社バラバラにそれらの機能を作っていってもいいのですが、 ある程度共通化して使える機能に関して WS- という接頭辞をつけた名前の仕様書がさまざまなベンダから提案されました(されています)。 具体的な仕様書名を挙げれば、たとえば WS-Security や WS-Addressing などです。

この WS-* 仕様群には、ベンダ各社の標準化競争だとか、 オーバースペックだとか CORBA の再来だとか、 さまざまな問題が指摘されています。 が、まあここではそういう話はおいておいて、純粋に技術的にどうなのかという議論をしたいと思います。

REST と SOAP

ここでは SOAP といったときに単純に SOAP エンベロープ形式を指すわけではありません。 SOAP というのはその周囲の WS-* だとか SOA だとかを含んだ一連のコンセプトを指すと考えます。

SOAP 的な考え方と REST 的な考え方(というか REST は考え方そのもの)の一番の大きな違いは、 プロトコル独立を重視するかどうかです。 SOAP 的考え方はプロトコル独立を重視します。 たとえば SOAP メッセージは HTTP でも SMTP でも UDP でも直接 TCP でも送れるように設計されています。 一方で REST には HTTP しかありません。 この両者の差は何なのでしょうか。

この差はインターフェースがどこに含まれるかの違いです。 REST では uniform interface 制約ということで HTTP が統一のインターフェースとなります。 HTTP の上をデータ(XML)が流れます。 一方で SOAP ではトランスポート独立ということで TCP, UDP, SMTP, そして HTTP の上に getX, startY などのインターフェース付きのデータ(SOAP メッセージ)が流れます。

REST と SOAP 的考え方の違い、少しだけですが雰囲気はつかめたでしょうか。 このテの話題は純粋に技術的ではなく、他の要素が絡むので語りにくいのですが、 技術者の皆さんに言いたいのは REST でも SOAP でも、 せめて技術的にはニュートラルに評価しましょう、ということです。 今日のこのポストもかなり端折って書いているので、 このまま鵜呑みにするんじゃなくて自分で調べてくださいね。

この REST 入門シリーズも次回はとうとう最終回です。