Subbu Allamaraju氏は自身のブログへの投稿で、現在のAPI実装の欠点とその改善方法について述べている。
Allamaraju氏によれば、APIのユーザは次のような問題に直面しているという。
インターフェイスのミスマッチ。 APIはその提供者によって作られるため、通常は彼らの考えを反映したものになる。利用と再利用を最大化することが、あらゆる利用者APIで最もよく見られる特徴だ。これは利用者がAPIのサブセットを任意の順序で呼び出すことでようやく目的が達成できるような、かなり粒度の細かいAPIを作ることへとつながることが多い。
このプロセスにおいて、（提供者は）利用者の特定の要求をトレードオフして、その共通項に固執することになります。これは利用者が必要とするものと（提供者が）提供するものとの間にミスマッチを生みます。
クライアント側では、時間のかかる、繰り返しの、冗長なコードを書くことになる。 粒度の細かいAPIを使うと、複数のAPI呼び出しの結果を集約しなくてはならない。
こうしたAPIをもつSDKを使うのをやめない限り、あなたは 2*n のHTTPリクエストを発行して、それらのレスポンスを処理するようなコードを書くのにかなりの時間を費やさなくてはなりません。
その上、各APIを実行するたびに、クライアントはリクエストを構築して、レスポンスをパースする必要がある。
提供者による機能強化には時間がかかる。 API提供者はたくさんの利用者をサポートしつつ、彼ら自身のスケジュールで仕事をする。往々にして、それは利用者のスケジュールとはかなりズレがある。したがって、特定のクライアントの要求と提供者のスケジュールを同期させるのは通常困難だ。さらに、提供者はAPIを再利用することで評価されるため、特定の利用者向けに一度きりのAPIを作成することを正当化するのは困難だ...
APIリクエストはおしゃべりなことが多い。 おしゃべりなクライアントを実行すると、複数のHTTPを呼び出して、かなりのパフォーマンス低下とネットワーク利用負荷を引き起こす。パフォーマンスとネットワーク利用の観点から、粒度があまり細かくないAPIを使う方がすぐれたアプローチであることは直感的に明らかだ。
一貫性のあるRESTful APIは思ったほど問題ではない。 Allamaraju氏によれば、API実装に一貫性が見られるのは理想的にはよいことだが、APIが提供すべき最も重要な機能は互換性だという。
私は一貫性の説教よりも互換性に自分の時間を使いたい。
総括して、Allamaraju氏はこう言う。
(大きな)クライアントアプリの課題はforkとjoinの集約、並列化、編成です。
では、どうすればこの問題を解決できるのだろうか？ Allamaraju氏はこう述べる。
... eBayの私のチームは、こうしたユースケースをシンプルにする新しいプラットフォームに取り組んでいます。
- APIを呼び出すコードを減らす。
- 必要に応じて自動的にAPI呼び出しをまとめる。
- 既存の提供者中心のAPIをラップした、新たな利用者中心のAPIを作る。
- バンド幅の使用と遅延を減らす。
こうしたプラットフォームを提案しているのはAllamaraju氏だけではない。QCon SFにおいて、NetFlixのDaniel Jacobson氏は現在実施している同様の解決策を紹介した。
Allamaraju氏とJacobson氏が提案した解決策には説得力があるが、Enterprise Service Bus (ESB)と何が違うのかと思うひともいるだろう。これはSOAの失敗の大きな理由のひとつと言われていなかっただろうか？ 問題はESBではなく、その間違った使い方にあったのだろうか？ 一般的にすぐれたパターンであり、今が2度目のチャンスを迎えているのだろうか？