エンドユーザー本位のサービス連携
現在のAPIによるサービス連携では、エンドユーザーが自発的にサービスを組み合わせるやりかたが当たり前になっている。
例えば、複数の金融機関が管理する口座情報を、フロントエンドを提供する別のサービス事業者が集約するケースでは、エンドユーザーがサービス事業者に対して口座情報への参照を許可するための手続きが行われる。逆に言えば、エンドユーザーの同意なしには、API連携が成り立たないかたちである。
2000年代初頭のウェブサービス連携の一般的な姿は、サービスを提供する事業者同士が主導し、機能をお互いに組み合わせることであり、連携可能なサービスは固定的であった。
実はその当時にも、リバティ・アライアンスという業界団体が「アイデンティティWebサービス」と銘打って、ユーザーの同意に基づくサービス連携を模索する動きもあったが、普及には至らなかった。
その背景としては仕様が複雑であったことが一番の原因だが、同時に、エンドユーザー自身がサービスを選択するという所作が受け入れられなかったことも少なからず影響している。
このようなエンドユーザーのマインドセットが、2010年代に入り、インターネット・サービスのプラクティスが浸透するにつれて変化していった。
たとえばFacebookのIDを使ってサービスにログインする際には、Facebookはエンドユーザーに対して、これからアクセスしようとしているサービスに対して氏名やメールアドレス、投稿した写真の参照権限を与えても良いかを確認する。
あるいはスマートフォンのメールアプリケーションにGoogleのGmailのアカウントを追加する際には、Googleはエンドユーザーに、そのメールアプリケーションに対するメールボックスや連絡先へのアクセス許可を確認する。
「インターネット・サービスの作法」に慣れたエンドユーザーは、自身のパーソナルデータや資産をサービスからサービスへ流通させる際に、それをどのようなサービスが、何のために使うのか、確認することを当然の権利であると理解するようになっているのだ。
企業は、APIによってつながる「エコシステム」の一部となり、顧客の「ビジネス・モーメント」に応える
これら、現在広く利用されているAPIに見られる2つの特徴から言えるのは、APIとは、2種類の利用者、つまりAPIを使ってクライアントアプリケーションを開発するデベロッパーと、そのアプリケーションを介してAPIを利用するエンドユーザーの、どちらにも受容されるものでなくてはならないということである。
この点こそが、過去、サービス事業者が自社の都合で提供していた前世代のAPIとの、大きな違いといえるだろう。開発者とエンドユーザーを取り込み、従来事業者単体ではなし得なかった新たなサービスを実現するということこそが、今日の「オープンAPI」の本質である。
