APIは企業の"プロダクト"である! 〜APIs as a Productという考え方〜

みなさんこんにちは!Red Hatのソリューションアーキテクトの手塚です。
今回はAPIs as a Productという考え方と、レッドハットが提供するAPI管理製品である3scale API Mangementでの実現方式の概要についてご紹介します。

ビジネスとしてのAPI

APIはご存知の通り、Application Programming Interfaceの頭文字であり、プログラム間のインタフェースを指す言葉です。
そのためOSのシステムコールもJavaのライブラリを呼び出すのもAPIですが、昨今のDXやAPIエコシステムの文脈で語られる場合には、APIはほぼWeb APIを指すため、この記事ではAPI = Web APIとして記載します。

様々なビジネスのデジタル化や、それに伴う既存の仕組みに囚われない人たちであるところのディスラプターの台頭によって、ビジネススピードの変遷が激化している今、いち早く企業の価値を顕在化するにはどうしたら良いのだろう?ということを実現するための取り組みとして、APIを活用する企業が増えています。
つまり既存/新規のアプリケーションを、APIという手足によって業種や会社を超えて連携し新たな価値を生み出したり、はたまた開発者へAPIという形で既存の機能をいつでも利用できるようにして開発効率を上げたり...etcということを行うことで、他社より少しでも早く、自社のビジネス価値を市場へを届ける、ということを行っているわけです。

したがってAPIは現在、単なるインタフェースを超えた、ビジネス価値を提供するアプリケーションとして捉えることができると言えるでしょう。

APIs as a Productという考え方

上記のように、APIをビジネスアプリケーション、つまり"プロダクト"として管理するにはどうしたら良いのでしょうか?

企業が公開しているプロダクトですので、市場にあるソフトウェアプロダクトと同様に、これらAPIがどんな顧客(=APIクライアント)に、どのように、どれくらい利用されるのかを管理し、日々顧客からのフィードバックを受けバージョンアップしていく必要があります(ちょうどソフトウェアプロダクトがアップデートされていくように)。
※ちなみに、社外公開のみならず、社内にのみ公開するというユースケースも非常に多くあります。

また、当然ながら顧客ごとに利用したいAPIやその利用用途は異なるため、顧客ごとにAPIの組み合わせや、それらのAPIを利用させる際のポリシーを定義してあげてはじめて、プロダクトとして成立することも考慮する必要があります(ちょうど使いたい機能群がひとつのソフトウェアプロダクトにまとまっているように)。

レッドハットでは、Red Hat 3scale API Management というAPI管理製品を提供しており、このAPIs as a Prodcutという考え方のもと、APIを管理、メンテナンスできるようになっています。

Red Hat 3scale API Management におけるAPIプロダクト

access.redhat.com

3scaleを利用することで、上記のように企業が提供するAPI(ここではバックエンドと呼びます)を顧客に応じて複数パッケージし、これらに適切な利用ポリシーを付与したものをプロダクトとして管理することが可能となります。

f:id:ytezuka:20200701011356p:plain

右側の、ぶどうの粒のようにたくさんあるのが企業内のAPI、つまりバックエンドです。
これをこのまま左側のAPIクライアント(顧客)に公開するのでは、APIクライアントから見ると非常に使いにくいはずです。
まずどのAPIがどこにあってどんな仕様なのかが不明でしょうし、もしかすると必要な認証方式もバラバラである可能性があります。
またAPIを公開する企業としても、バックエンドを不正なAPIクライアントから保護したり、またどのAPIクライアントがいつどれだけ、どのバックエンドにアクセスしたかを知ることは容易ではありません。

そこで3scaleは両者の間をプロキシし、任意のバックエンド群をプロダクトとして公開することでこれらの課題を解決します。

まず、管理単位であるプロダクトを登録し、そこに任意のバックエンドを登録します。これは1つでも良いですし複数でも構いません。 そしてこのプロダクトに対し、様々な設定やポリシーを定義、または必要になった際に更新していきます。
例えばこのプロダクトを利用可能なAPIクライアントの登録や、必要な認証方式、アプリケーションプランと呼ばれる利用可能コール数の設定や、ルーティングの設定、プロダクトがコールされた際に実行される各種ポリシー(ソースIPアドレスをチェックする、流量制御を行う、JWTを検証する...etc)の設定などです。
また公開されているAPI仕様をOpenAPI Specとしてデベロッパーポータルへ登録しておくことにより、APIクライアントはポータルを確認することでいつでもプロダクトの仕様を確認することが可能になりますし、管理者ポータルからは各プロダクトがどのAPIクライアントからどれだけ利用されているか、という情報を一元管理することが可能です。

上記により、顧客からはバックエンド群がどのようになっているかを意識することなく、プロダクトとして公開されている仕様から各種バックエンドへアクセスが可能になりますし、API公開者はプロダクトに定義した内容に沿って、バックエンドを保護し、利用実態を分析することが可能になります。
つまり公開するAPIをビジネスプロダクトとして扱える、ということになるのです。

おわりに

冒頭にも述べたように、DXが進みAPIエコシステムが進んでいくと、企業にとって自らのAPIをプロダクトとして管理することが非常に重要になってきます。
もしこれらの課題でお悩みの方がいらっしゃいましたら、どうぞお気軽にレッドハットまでご相談ください!

それでは素敵なAPIライフを♪

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。