RESTに対する７つの誤解

海外に行くと、既に REST対SOAPの決着は付いている^[1]（エンタープライズでもコンシューマでも）ように見えるのだが、日本国内で話していると、まだまだ混乱しているようだ。さながら2009年ごろの状況を見るようだ。そこで、今日は RESTに関わる誤解について、幾つか書いてみたいと思う。（殴り書きだが、あんまり聞かれるのでFAQとして。なお、以下の多くは、[2] サービスステーション：RESTの詳細でより詳細に書かれている。）

誤解1. RESTはマッシュアップ用のプロトコルで、サーバ間通信には適さないのではないか？

どこからこのような誤解が来ているのか理解に苦しむ。ひょっとすると、RESTはHTTPベースということが、ブラウザとWebサーバのやり取りという風に誤って捉えられているのかもしれない。

もちろん間違いである。

ブラウザとWebサーバとの間同様、サーバからサーバへの通信にもHTTPは非常に便利である。

誤解2. RESTはSOAPに比べてセキュリティレベルが劣るのではないか？

この質問に対する答えも明らかにNOである。このような質問にフラストレーションを貯めるのは、なにも私だけではないようだ（[2]参照) SOAP関連の仕様であるWS-*は、様々な複雑なメカニズムを持っている。その中には多くのセキュリティメカニズムが入っているし、その中にはメッセージレベルの暗号化を通じて、メッセージが転々流通してもセキュリティが守られるような仕組みがある。これに対して、RESTは極めて単純であり、それ自体ではメッセージ暗号化の仕組みを持たない。が、それはSOAPでも同じ事で、WS-*の追加仕様によってこれが実現されているのである。RESTでも同様に、メッセージをたとえばJWEなどで暗号化すれば事足りるのであり、結局は同じことである。

むしろ、この手のことは実際の運用のほうが大きな要因であることが多い。たとえば、SOAPでXML Encryption を使って通信していたとしよう。この時、暗号化のモードがCBC（←現在もっとも多く使われている）であるならば、エラーの返し方を気を付けないとセキュリティホールを産んでしまう。（実際、多くの実装はセキュリティホールを持っていると思われる。）SOAPとかRESTとかのレベルでセキュリティ云々いうのは不毛である。

誤解3. RESTはトランザクション処理には使えないのではないか？

確かに、SOAP+WS-*は、素のRESTではサポートしない高度な分散トランザクション機能をサポートする。これに対して素のRESTだと、手動コーディングが必要になる。だが、そのようなSOAP+WS-*のメリットは、２つのエンドポイント間の密結合という代償の上に成り立っていることも忘れてはならない。現代的なシステムでは、密結合を避け、他にやり方がないかを模索するであろう。そもそも、atomic な分散トランザクションが必要な設計を見直すというところからはじめて。

誤解4. SOAPは相互運用性が考慮されており、RESTよりも相互運用性が高い。

これもまた完全な誤解である。[2] でフランダース氏が言っているように、相互運用性を２つのエンドポイントの間で通信を行う技術能力というふうに定義すると、明らかにRESTの方が相互運用性が高い。これは、RESTが単純な標準技術によって構成されているのに対して、SOAP+WS-* は膨大な仕様群の組み合わせからなっているというところに起因している。同じ機能で会っても、ベンダー製品ごとに微妙に使っている仕様やパラメータが違っていたりなど、結局は同一ベンダーに囲い込まれないと繋がらないというような悲劇に見舞われやすいのだ。

これに対して、RESTが要求するのは基本的にHTTPスタックだけである。これは、サーバだけでなくPCにも携帯電話にも、ありとあらゆるところでサポートされている。このことは、相互運用性という意味で、大きな利点となるのである。

誤解5. WSDLがあるから、SOAPの方がプログラムを書くのが簡単だ。

確かにWSDLは便利である。なのに、なぜ後発のRESTのフレームワークの多くはWSDL様のものを持っていないのだろうか？

答えは、「いらないほど簡単だから」、だろう。[3]

誤解6. RESTはコンシューマ向き、SOAPはエンタープライズ向きである

何を持ってエンタープライズ向きと捉えるかによるが、多くの人が言うように、スケーラビリティとアプリケーション拡張性をその特徴として捉えるならば、実はRESTの方がエンタープライズ向きである。

スケーラビリティという点では、インターネット上の大規模サービスがほとんどRESTを採用していることからもRESTの方が有利であるのはみなさんもお分かりであろう。実際、サーバが状態を保持しなくて良いということや、HTTPのキャッシュなどをフル活用できるというRESTfulの特徴こそが、このような大規模サービスを可能にしていると言っても過言ではない。

また、アプリケーション拡張性ということで考えると、複数のシステムを有機的に接続して行くことが一つの鍵となる。例えば、クラウド上のシステムと組み合わせて使うなどである。この場合にも、疎結合なRESTは、密結合が要求されるSOAP+WS-*より有利である。現代的なビジネスニーズには、かえってRESTの方が向いているとも言えるのだ。

誤解7. じゃぁ、何でもかんでもRESTにすればいいんですね？

いやいや、ちょっと待って。RESTにせよ、SOAP+WS-* にせよ、所詮はツールである。RESTに向かないところまでわざわざRESTでやる必要はない。たとえば、プロトコルがSMTPである必要がある場合などは、RESTよりもSOAPの方が向いているだろう。

こうしたことを考えると、アーキテクチャを選ぶときの現状のベストプラクティスは、

1. まずRESTでできないかを考える。
2. RESTでできない部分については別の方策（例：SOAP）を考える。

うまく適材適所にしていくのが肝要である。

[1] 今時、SOAPでやりたいという人にお目にかかるほうが難しい。もっとも、RESTとSOAPをダイレクトに比較するというのも、あんまりフェアではないのだが。（追記：以下の[2]が解説しているように、RESTはアーキテクチャスタイル、SOAPは2 つのエンドポイント間でデータを交換するためのプロトコル仕様で、直接比較するのはみかんとリンゴを比べるようなもので不毛である。[2]も合わせて読まれることを前提にしているので分かると思うが念のため。(11/22)）

[2] http://msdn.microsoft.com/ja-jp/magazine/dd942839.aspx

[3] 「要らないほど簡単だから」ではなく、「要らないほど単機能だから」ではないかという指摘あり。確かに。もっというと、要らなくなるまで分解してしまうからとも言えるかも。一方では、REST好きの人は、APIが隠蔽されるのを嫌う傾向にあるような気もする。手書きできるというのが、結構重要なデザイン上の考慮点だったりするのも影響しているかもしれない。(11/22追記)