Enterprise API とPlatformについて

「Enterprise APIs Advent Calendar 2015 の１３日目の記事です。」

日経新聞(11/17) 柳川東大教授の「エコノミクス・トレンド」という記事を読んだ。
それは、これまでのパッケージアプリケーションなどの機能を部分的に切り出してオープン化し、他企業の利用を促進することで思いがけない「組み合わせ」を期待するという話であった。

想定しない新たな組み合わせが新しい大きな価値を生むが、そのためには他社をひきつけるプラットフォームが重要ということらしい。

今回はこのプラットフォームの実装面についてAPIとアーキテクチャーの観点から述べてみたい。

オープン化とプラットフォーム戦略

概要は次のとおりである。

• 自社の強みのある部分、いわゆるコアコンピタンスの部分に特化してしまって、他は優れた外部を組み合わせた方が良い場合も出てくるだろう。

• また、単にコアコンピタンスを生かすだけでなく、他が参加しやすい「舞台」を用意する「プラットフォーム戦略」がポイントになる。

• 多くの他事業者あるいは消費者が積極的に利用するようなシステム、サービス、あるいは規格といったものをプラットフォームと呼ぶ。

• 強力なプラットフォームは新しい企業が参加しやすい「舞台」となり、新しい組み合わせをひきつける力となりうる。

• 開発の基盤となるようなシステム、利用しやすいサービスや規格はプラットフォームとして外部に提供できる。

• それを利用する事業者やベンチャー企業をできるだけ増やすことができれば、プラットフォームの魅力が高まり、新しい組み合わせの可能性も広がってくる。

これはまさにEnterprise APIが狙っているところであり、コアコンピタンスのオープン化とはつまりAPIを公開することに等しいのだろう。
ここまでは誰にでもわかる話だが、問題はそのような魅力的なプラットフォームを具体的にどのように実装するかということである。

プラットフォームにおけるAPI利用の形

それぞれが単にAPIを公開しただけでは「他社をひきつけるプラットフォーム」が自然発生するなんてことはないだろう。それほど甘くないことはわかる。
少なくともプラットフォームではAPIをどう利用するかについて標準的なデザインパターンを用意する必要があると思う。

ここでまずAPI利用の基本的な形について整理しておきたい。



最上段の①がモノリシックな３階層のWebシステムで、真ん中の②がそれをMicroservicesにした形、最下段の③がいわゆるサーバレスアーキテクチャーといわれる形である。

重要なのはControllerであり、プラットフォームがそれを提供しなければならないということ。また、Same Origin Policyを基本とする標準的なWebのルールに則る必要がある。

③のサーバレスアーキテクチャーは今注目されているパターンだが個人的には筋が悪いと思っている。
それは、XHR2のCORS対応で頑張って異なるサーバ同士を繋げることができたとしても、クライアントから直接モデルを更新できるため、例えば、ECにおける商品金額のマスターチェックを回避するなどの不正を防ぐことができない。
金額を正確にチェックするにはサーバ側でマスター参照しなければならず、そのためにサーバ側にもロジックを置く必要がでてくる。となると②と大して変わらないということになる。(※ 金額チェックはモデルで実行すべきと考えられるがサーバ側に固有のロジックを置くのは馴染まない)

というわけで、基本的には②の形がプラットフォームの標準的なデザインパターンになっていくのではないかと思う。

Controllerを跨ぐ連携の必要性

APIの利用は上述したようにcontrollerを介して行われるが、今後はControlerまたぎのAPI連携をも想定する必要があると思う。
つまり、異なる企業がそれぞれの機能をコンポーネント化して外部に公開することを考えると、異なるドメインにおける画面遷移を意識した作りにならざるを得ない。

例えば、ECにおける受注機能と出荷機能の連携では、出荷画面に遷移して伝票を印刷してまた受注画面に戻るといったような画面遷移を伴うアプリケーションの事例もある。

このように、API連携だけでなく異なるドメインの画面遷移を伴うようなWebアプリケーション連携についても標準的なデザインパターンを考えていく必要があるように思う。

この場合、もはやAPIと言っていいかどうかはわからないが。

ところで、12/16(水)にセミナーをやるので、興味のある方はぜひご参加ください。 Qiitaの記事も毎日更新しています。