API が Web を変えています – 私たちの周囲で徐々にその存在を増しながら，アプリケーションにエキサイティングで新たな可能性を作り出しているのです。Programmable Web は 2005 年から，一般公開された SOAP API と REST API の追跡調査を実施しています。2005 年に彼らは Amazon や Google, SalesForce, eBay など，知名度の高い 105 の API を調査しました。その後，ソーシャルメディアや従来型メディアがサードパーティへのデータ公開のメリットを認識したことで，2008 年までにその数は６倍の 601 にまで増加しました。そして 2010 年の末には，開発者が自由に利用可能な API 数は 2,500 を越えています。Zappos のような先進的な考えを持つ企業が REST API を公開する一方で，政府機関 や レンガ & モルタル 方式の従来型小売店もこの競争に加わっています。Tesco では食料雑貨の注文が可能です。Instagram は Twitter の写真版を開発しました。Face は顔認識技術をサービス形式で提供しています。Twilio の API コールを組み合わせればテレフォニーアプリケーションが開発できます。2011 年内に公開 API の数は 5,000 に達するでしょう。キラーアプリケーションを開発するのに，これ以上の機会はありません。
出典: Programmable Web
SOA の見果てぬ夢 (Holy Grail)
過去10年間にエンタープライズシステムに従事した経験を持つ開発者であれば，サービス指向アーキテクチャの初期の信条を覚えていることでしょう。それはアプリケーション間の分離と明確に定義されたインターフェースの提供，それによるアプリケーションの再利用とビジネスプロセスへの部品化，というものでした。再利用と部品化，この２つのアイデアで SOA は注目を集める提案となり，何千という組織を宝探しの冒険へと誘ったのです。以来，SOA に対する 死亡宣告 と 復活宣言，さらには数多くの苦難の物語といくつかの成功物語を目にしてきましたが，目標に到達したという例はほとんどありません。しかしその過程で Web は，API を通じて情報と機能の提供を実現することによって，本質的にサービス指向プラットフォームとなりました。エンタープライズシステムが果たせなかった目標を Web が達成したのです。
Web が成功した要因は，アプローチが分散的である，適用される技術的制約の少なさがサービス指向に適している，などの事実に見ることができます。初期の API には SOAP で記述されたものが多くありましたが，現在の主流は REST (レベルのばらつきはありますが) です。公開される REST API の数も急速に増えています。
出典: Programmable Web
SOAP API と REST API を両方とも提供しているものもありますが，実例としては少なくなっています。現在は新しい API の大部分が REST を選択しています。
出典: Programmable Web
XML か JSON か
Web において REST が好まれる理由のひとつとして，クライアントのアクセス性があります。エンタープライズを念頭において定義された SOAP では，プラットフォームに依存しないプロトコルが採用されています。この SOAP XML には冗長性があり，JavaScript や Ruby などの Web 技術で扱うには少なからぬ苦痛を伴います。これに対して JSON は，表現のコンパクトさ，可読性のよさ，JavaScript のネイティブフォーマットである点などが好まれています。興味深いことに新しい API ほど，対応を JSON に限定するものが増えてきています。現時点で API の 45% が JSON をサポートしていますが，その中には JSON を唯一のデータ形式としてサポートする新しい API が多数含まれています。
出典: Programmable Web
REST 実装の苦難
API に移行する上での最大の課題は REST の本質にあります。REST (Representational State Transfer) は HTTP 上の対話モデルを定義するアーキテクチャスタイルのひとつで，HTTP 動詞 (verb) をユーザのリストやアカウントの更新，オーダエントリの削除などの動作を行うサービス操作にマップするものです。原理的には Roy Fielding 氏が 2000 年に発表した論文 を基にしています。以来 REST は，あらゆる形式でソフトウェア開発における基盤を強固なものにしてきました。その最大の問題点は，論文での定義が一連の制約についてのみであることです。URL スキーマやバージョニング，認証処理，エラー処理 (HTTP コードでは不十分)，さらには RESTful なリソースにパラメータを渡す方法などについては何も規定されていません。RESTafarian (REST主義者) の強硬な反発があるかも知れませんが，彼らに真っ向から対立する意見をあえて述べるならば，他の部分 (REST) には合意された方法が存在していないのです。
REST は人それぞれ
RESTful なアーキテクチャ構築の正しい方法は明確に定義されていません。サードパーティの REST API を使って開発を行うと，REST にはさまざまな解釈があって，それが他の API の使用を難しくしていることに気が付くでしょう。いくつか例をあげると、
- 同じプロバイダによる API 間でさえ，認証に一貫性がない。
- HTTP 動詞の使用方法に一貫性がない。他のすべてのものと同じく，REST も人為的ミスや誤解の影響を受ける。
- HTTP 戻りコードの定義に一貫性がない。明確に定義されたエラー処理スキームがない。充実したエラー処理を備えた API もあれば，ほとんど何もないものもある。HTTP の戻り値では不十分だ。
- REST のモデルに適さない，さまざまな URI スキームが存在する。
- バージョニングを行うための合意された方法がない。REST API がアプリケーションへのゲートウェイであることを考えると，これは重要な問題だ。
- REST API コールのハッシュと署名パラメータが煩雑である上に，異なる API 間での一貫性がまったくない。
- サービス間の要求および応答メッセージに一貫性のないものが多く，クエリとオブジェクトのバインディングが難しい。 また DTO (Data Transfer Object) の生成に明確なガイドラインがない。
- SOAP ベースの Web サービスとは違い，自己記述的でない REST には通常コントラクト(contract) が存在しないため，API の変更に関する警告がない。
開発者にとっての API
公開された API は当然ながら，開発者自身のコードから直接コール可能です。ただしこの方法では不都合な場面もあります。Facebook のみにアクセスするような場合ならば何の問題もないのですが，複数の API を使うアプリケーションを構成するのであれば，新たなアプローチが必要になります。また多くの API ベンダが開発者の便宜を考えて PHP，Ruby，Java でのクライアントサポートを提供していますが，メンテナンスされていないものも多数あるため，利用する上での負担はこれらクライアントによって異なります。
API を受け入れる
公開 API の数は年を追って倍増しているので，これらの新しい機能の価値を無視することはできません。一方で API 間に大きな差異があるという REST の問題には，解決のために開発者を補助する手段が必要です。API クライアントが期待を満足しないことが多々あることから，API Smith などのフレームワーク，あるいは多数のソーシャルメディア API に一貫した API インターフェースを提供する Gnip のような API サービスが現れました。さらには apigee や Mashery といった企業が API を 検索する ツールを提供しています。
別の方法
API を受け入れる上での私たちのアプローチは，一貫性のある操作モデルを提供することです。Mule Cloud Connect がそれを提供します。このモデルでは，API は URI スキームや認証，サイン，ハッシュ，セッション管理，イベントストリーミングなどを扱うアノテーションで修飾されたメタデータを持った，単純なオブジェクトとして表現されます。
このようなオブジェクト (クラウドコネクタ) を用いて 携帯電話にアップデート送信するソーシャルメディアデータのフィルタ や 請求先への自動音声アクセス，あるいは CRM データのデータベースへのバックアップ などのフローを構成することができるのです。
フローには当然ながら，それを実行する場所が必要です。統合プラットフォーム・アズ・ア・サービス (iPaaS) の Mule iON は，開発者が API 機能を構成して，その結果を自身のアプリケーションにパブリッシュすることを可能にします。Mule iON はアプリケーションの統合レイヤとして動作して，アプリケーションコードの統合ロジックを不要にします。
iPaaS の意義は，統合ロジックをアプリケーションから分離可能にすることにあります。複数の API を使用する場合，アプリケーションには各 API に対応する特殊なコードが必要になります。API のいずれかが変更されれば，対応するアプリケーションコードも更新しなければなりません。iPaaS では，この種のロジックをすべて統合レイヤに移動することができます。セキュリティや再試行，セッション管理，処理量調整やエラーなどを扱う API に個別対応するためには，統合レイヤはアプリケーションよりもはるかに適した場所なのです。iPaaS はモバイルアプリケーションあるいは Web アプリケーションに対して，それが従来のホスト形式であるか，Heroku や force.com，CloudBees, Azure といった PaaS 上のものであるかに関わらず，データあるいは機能の結果を公開 (マッシュアップ) することができます。
急増する Web 上の API は開発者にとって，アプリケーション組み込み可能な新たな機能とデータの宝庫です。これらの API を利用することで，より多くのコンテキストでさらに面白いユーザエクスペリエンスを提供するアプリケーションが，新たに数多く開発されています。一方では API の標準が存在しないことが，異なるプロバイダの API を併用する開発で大きな問題となっています。開発者は，統合ロジックをアプリケーションからプラットフォーム固有の処理に移動することによって，自身のアプリケーションコードをクリーンに保つ方法を探さなければなりません。
著者:
Ross Mason 氏は MuleSoft の創設者で CTO です。氏は 2003 年に，オープンソースの Mule プロジェクトを設立しました。統合にまつわる "くだらない作業" に不満を感じた氏は，開発の容易性とコンポーネントの再利用性を特徴とする，新たなプラットフォームの開発に着手しました。反復的なコーディングに代わる１つのアセンブリ，という現代的なアプローチを世界中の開発者に提供するため，氏は Mule プロジェクトを立ち上げました。現在の氏は MuleSoft のチームで，極限的にシンプルな統合の基本原則をクラウドに展開すべく，世界最初の統合プラットフォーム・アズ・ア・サービス (iPaaS) である Mule iON の開発に従事しています。氏は英国ブリストルでコンピュータサイエンスの理学士(優等学位)を取得し，InformationWeek のトップ10イノベータ・アンド・インフルエンサ，およびInfoWord のトップ 25 CTO の栄誉を受けています。Twitter: @rossmason, @mulejockey