Programmable Webのデータによる、APIの73％が RESTfulであることを基に、RESTは勝利した、と早合点する人達がいるかもしれない。しかしSOAの実践者である Steve Jones氏は、それらのAPIはデータ収集するフロントエンド システムで使われており、エンタープライズ システムの大部分によっては使われていないし、RESTはまだエンタープライズに対応出来ていない、と注意喚起している。
Masheryの前CTOであるClay Loveless氏は、Glue Con 2011で「SOA失敗の教訓」という講演の中で、APIリソース索引作成のProgrammable Webによる統計について話し、ここ数年SOAPは伸びているが、堅実に伸びているRESTに比べてずっと割合が小さいことを示した。
これらの数値に対して、Capgemini にあるMaster Data ManagementのGlobal Headであり、SOAの実践者である Steve Jones氏は、これらの数値は 現在のREST/SOAPの使われ方を正確に表しておらず、その理由として Programmable Webがエンタープライズ データを集めていない、と言っている。
では、 Oracle, SAP, IBM あるいは Microsoftのエンタープライズ技術スタックが提供している同類のものに同じクエリをしたらどうでしょうか？私は相当な数になり、真面目にサーチするだろう、と思いました。しかし出てきた数は 2368 エーこれってマジ？私は１企業で働いていますが、SOAPエンドポイントの数はこれよりも多いです。SAPやOracleが公開しているWSDLのライブラリを含んだら、 Oracle AIA であるBehemothは非常に多くて、複雑に見えてしまうのでOracleはそれを自慢になんかできません。2005年にOracleは全アプリケーションで3000webサービスを誇ってましたが。
REST 対SOAPの議論で、ReadWriteWeb の編集者である Alex Williams氏はGlue Conでのレポート でSOAPは死んでいないが「完全には死んでいないが、ここしばらくもこのままだろう」と言っている。というのもSOAPは企業で定着しており、無くすのは難しいのがその理由だ、としている。
Jones氏はWilliams氏の投稿にコメントして、SOAPは企業でしっかり生きており、 RESTはまだ生まれたてである、と言っている。
SOAPは死にそうなのではなく、企業でしっかり生きていて、実際のところ、幾つものベンダー（エンタープライズITの大きな部分）からのパッケージ ソシューションを統合しようとすると、唯一の実現可能なアプローチです。しかし、RESTはほとんど登録されていません。ここ数年の開発で2500APIに達しないでしょう。哀れなものです。
エンタープライズ向けRESTは死にそうなのではありません。5年以上に渡って今だに生まれたばかりなのです。
Jones氏は他の投稿で、この1年 RESTはエンタープライズ統合において進んでいません 、政府機関でも。その原因はパブリケーション、バージョン付け、テストにあります。
はっきり言いますが、ここで私がRESTについて話すのは、エンタープライズ統合アプローチとしてであり、コンテンツ収集用のweb APIの見せ方ではありません、企業にとっての機能的統合アプローチとしてです。「根本的に欠点のある」WS-*を置き換えるものです。RESTのがずっといいです。さて、今年はどんな進展があるでしょう？ゼロ、０、全くなし。RESTインターフェースを生成できるエンタープライズ スタックに2,3の小さな調整が入りました。しかし実際のところ、ほとんど生成できません。インターフェース公開、バージョン付、テストに存在する重要な問題が未解決のままなのです。
InfoQは Programmable Webの設立者である Clay Loveless とJohn Musserの両氏に話をし、企業とRESTに関するJones氏の投稿への反応を得ようとした。
Loveless氏はSOAPがしばらく企業で生き長らえることには同意したが、結局RESTが主流になると語った。
私が私の話の中で、SOAPが特に企業内で長い間使われ続けるだろう、という重要なことを Steve Jones氏が示したのだ、と考えています。
企業が変化を受け入れるのには時間がかかります。ベンダーと顧客間の関係に大きく依存しています。もし企業の中間管理職がどこかのサポート契約にお金をつぎ込めないと、ちゃんと仕事をしていない、ように感じるのです。
企業はいつも、そしていつまでもコマーシャル市場の後追いです。コマーシャル、B2Cの世界ではRESTが優ってます。John Musser氏の数がそれを証明しています。会社は効果的にSOAエンジニアを雇用できないこと、そしてRESTで速く安く作れることに気づき始めてたら、シフトが始まるでしょう。これはしばらく起きないでしょうが起きます。また印刷機械は死にかかっています。Blackberryのように。両陣営の多くがそのことを否定するのに忙しいですが。
Glue Con 2011の基調講演でAPIの状況について話したMusser氏は上記のチャートにある同じデータを示して、トレンドは変わらず、結局RESTが企業も制覇する、と信じている。
企業内ではこれからも長くSOAP APIが使われるだろう、という Steve とClay両氏の意見に同意します。REST対SOAPの技術的な判断で決まるのではなく、技術的なメリットやCIOオフィスからの決定でもありません。存在期間が主要因なのです。Steve氏が指摘したようにSOAPやWS-*技術を使った膨大な数のアプリケーションやたくさんの企業向けツールがあるのです。
先週の私の話の中で参照したように、2005年を振り返るとwebベースAPIにおいてはSOAPは本当に強かったですが、この6年間で明らかにRESTが市場の大きなシェアをどんどん取っています。今日の実装やエンドポイントの総数はそれほどではありませんが、そのような傾向なのです。もちろんSOAPが捨て去られるわけではありませんが、Salesforce.comがやっていることを見てください（ほぼ10年間SOAPだけでしたが、今やRESTや Microsoftの Azure プラットフォームを採用しています）。
我々はまた Steve Jones氏と話し、なぜ彼はRESTがエンタープライズに合わないと考えているかを詳しく聞いた。
InfoQ: あなたは、RESTはこの1年EA統合において全く進歩していない、と仰てますが、何に基づいた発言ですか？何か数字をお持ちですか？それはあなたが働いている企業内の経験にもとづく話でしょうか？
SJ: 私は企業内のあるREST開発を見てきましたが、いつも方程式のWebエンドで、エンタープライズシステム間の内部的統合に関する仕事ではありません。私はまた Programmable Webの統計からも全くそうです。例えば、彼らのSAPリンク (https://streamwork.com/developers) は、実際REST APIであり、RESTが機能しているところで動いています。フロントエンド統合と収集です。
Programmable Webは2500未満のAPIを並べており、SAPからだけでOracleからのものはありません。このことは、まさにRESTコミュニティがいかに認識されていないかを示しており、それはエンタープライズ統合の現実と挑戦です。
InfoQ: あなたはコンテンツ収集ではRESTは進展しているが、ES統合においては進歩していない、と言ってます。この2つのドメインの違いは何ですか？EA統合にとって有益なものはなんでしょうか？インターフェース パブリッシュやバージョン付けですか？
SJ: データ対関数です。１ページに表示されている5つの違うシステムからの全アカウントを見たいと思ったら、RESTのアプローチは素晴らしいです（MDMソリューションがバックで動き、各システムで顧客キーが識別できる限りはですね）。しかし5つのアカウントをオープンして、請求システムと通信して、チームが独立に働けるような方法（これは非常に重要なことです）でそうできるものを作りたいと思ったら、RESTでは破綻します。
エンタープライズ統合とは、ドメインが充分定義された境界を基に、独立して働けるようにする、ドメインの分離です。これらの分離は、しばしば仕事をアウトソーシングすることで契約的に強制されるか、パッケージ ベンダーによって技術的に縛られます。RESTの精神では、これらの境界は流動的で、ガチガチにするのは問題です。現実は、境界をきっちり決めることは、実際いいことで、それによってチームは独立して働けます。このため、複数技術スタックで消費できる機能的契約（WSDL)をパブリッシュする能力は、SOAP/WS-*の重要な利点です。
RESTとMDMに絞れば、これは境界のいい例です。RESTは同じ顧客について複数のシステムから情報を集めることが出来る必要があります。「真の」RESTアプローチは中心的顧客システムを持ち全ての人々はURIを介してこのシステムを参照します。このためURIはユニークなIDとなります。現実は、SAPやOracleのようなシステムは常に顧客情報のローカルコピーを持つことになり、ある形式の機能的統合と情報の同期が必要になります。「顧客作成」機能と「顧客同期」返り値の両方をパブリッシュするWS-*が、ここで出番があるわけです。
純粋に技術的観点からSOAPとRESTの違いを議論することは無意味なことです (http://service-architecture.blogspot.com/2006/05/soap-v-rest-more-pointless-than-vi-v.html, http://service-architecture.blogspot.com/2006/09/why-rest-v-ws-is-irrelevant-in-two.html)。現実的には、エンタープライズが統合する必要があるのは契約をパブリッシュする能力で、契約は単に技術的な意味で消費できるのではなく、いかに能力を呼び起こすかを理解する、実際の人間的な意味においてです。このことは、その過ちに対するWSDLのほうがRESTよりも簡単です。
実際のエンタープライズ統合では、修繕に使われる特別な技術よりMDMのようなアプローチをとるほうが統合の複雑さや柔軟性に対してずっと大きな効果があります。
InfoQ: RESTの将来をどう考えますか？
SJ: REST信奉者の多くは他のものじゃ駄目だ、と言ってますが過去から現在までに溜まっている実際の欠陥を無視しています。私は期待しているのは、RESTの人達が目を覚ましてRESTの機能的インターフェースを書く標準的なやり方に同意しようとすることです (http://service-architecture.blogspot.com/2010/01/define-standards-first.html) 。これは本当に基本的なことですが、多くの人々はこれはRESTの原則に反する、と言っているのです。おそらく問題の本質は、RESTは基本的にデータ探索と収集をするもので、より機能指向的なアプローチには合っていないのでしょう。
InfoQ: もしRESTがソリューションでなくSOAPがその複雑さを非難されるのであれば、EA統合の将来をどう考えますか？
SJ: エンタープライズ統合は複雑です。それは大抵のWeb統合よりも複雑です。人々はWeb統合は高パフォーマンス故に複雑だと考えていますが。スピード イコール 複雑さではありません。エンタープライズ統合に複雑さがありますが、RESTとSOAPの技術的な差から来るところはほとんどありません。RESTは今日企業プログラマーにとって著しく複雑です。それは機能的インターフェースを定義する標準的な方法に同意できないためです。
エンタープライズ及びB2B統合を改善するアプローチは、これらのインターフェースにもっと公式化を追加できる能力でしょう。そうなると任意な文書化が少なくなります。例えば将来の誕生日を特定できたり、あるいはクレジットカードのチェックがアカウントを開く前に実行するようにできることは、非常に役立つでしょう。
B2Bやエンタープライズ統合の複雑さでSOAPを責めると、複雑さの原因が的はずれなものになってしまう。複雑さは、複数の異なるビジネスドメインを統合するニーズとこれを容易にするコアビジネスと技術アプローチ（MDMのような）に標準を欠いていることから来るのです。技術的修繕アプローチは線上にXMLを送るだけで、SOAPの方が古いアプローチよりもこのことを簡単にできます。RESTでは簡単になりません、だから使われていないのです。
Jones氏は Twitter@mosesjonesで次のように付け加えている。私は間違っているかもしれない。RESTが企業でも優位に立つかもしれないが、REST族は技術的であるより実践的であるように勤めなければならない。
あなたの経験はどうか？RESTは、あなたの企業に合っているだろうか？Jones氏が言った問題をあなたは解決したことがあるか？あなたは企業で将来、RESTがSOAPに代わると思うか？