Azure API Managementに基づく成功したAPI収益化プラクティス

みなさんこんにちは！

今日は、API管理のトピックについて説明します。 APIを開くことが理にかなっている場合、誰がAPIを収益化する機会があり、初期実装とその運用の両方のコストが最小限になるように管理APIシステムを実装する方法があります。







Azure API Managementに基づいたAPI管理システムの開発における経験を共有したいと考えています。 最初から始めましょう。

1. LIKBEZ。 APIを管理する必要がある場合

1.1。 APIを開くタイミング

自分のデータ、コンテンツ、または独自のビジネスロジックが他の企業や人々にとって役立つ可能性があることを理解している場合は、APIを開くことができます。



APIがユーザーのビジネス拡大に役立つことを理解したら、APIへのアクセスを有料で提供できます。

ユーザーが少ない場合は、手動でアクセスを提供し、料金を徴収できます。 また、多数ある場合は、おそらくAPI管理システムが必要になります。 （API管理システム）。



1.2。 API管理システムが必要なのはなぜですか？

要するに、システムのAPI管理の目的は、APIを製品に変えることです。 実際のビジネスコンテンツに純粋に技術的な本質を与えるため。 現在、ほとんどのシステム管理APIは次のことができます。

• APIへのアクセスを整理します。
• API使用ポリシー（要求の完全性、その頻度、時間単位ごとの制限）を定義します。
• APIドキュメントツールを提供します。
• *ポリシーに基づいて有料のAPIアクセスを整理します。

2.すべてのAPI管理システムが同等に役立つわけではありません

当社の顧客は大規模な気象会社であり、そのビジネスの大部分は気象観測所から受信した有料データの提供です。 数年前、彼女は業界でも最初に有料APIを開いて提供した人物の1人でした。 現在、14種類のAPI製品をお客様に提供していますが、製品に含まれるAPIセットと、製品セットの使用制限は異なります。



プロジェクトの範囲を理解するために、現時点では、顧客のAPIは4200人の開発者、2400社で使用されています。



共同の歴史は、サービスの収益化を成功させるためにAPI管理システムを実装しようとするお客様による3回目の試みです。 1回目はMashery、2回目はApigee、Azure API Managementに基づいたソリューションでした。 いつものように、ロシアの伝統では、3回目から、通常すべてが成功します。 ここでそのようになった。



その結果、基本的にカスタムAPI管理ソリューションを作成しました。

• 統合されたAzure API Managementと顧客IDおよびサブスクリプション管理。
• カスタマーポータルとAzure API Managementポータルを操作するためのシングルサインオンを提供しました。
• PayPalを介して支払いを行い、SalesForce CRMシステムと統合しました。

2.1。 そして、最初の2つは何が悪かったのですか？

私たちは、会社が両方の時代にマーケットリーダーであるMasheryとApigeeを選んだという事実から始める必要があります。 そして、1年使用した後、彼らはそれぞれを残しました。 ちょっと変に聞こえます。 これらはリーダーですか？！







実際、API管理システムの要件は、主に2つのポイントに削減できます。

1. 使用コスト
2. UX、およびユーザーと管理者の両方のUX

そして正確にこれらのパラメーターについては、主要なシステムは顧客に受け入れられませんでした。



2.2。 使用コスト

Masheryの収益化スキームでは、事前に予測可能な費用の見積もりができず、すぐに非常に高くなりました。



統合された支払いシステムでApigeeを使用するコストはただのスペースであり、本質的にAPIの販売からすべての収益を奪いました。



Azure APIMには統合された支払いシステムがないと言わなければなりません。 一見したところ、これは大きなマイナスのように見えますが、組み込みの支払いシステムでの維持が高価であることが判明した否定的な経験の後、顧客はこれを絶対プラスと評価しました。



2.3。 Ux

さらに、顧客はApigee UIが複雑すぎてわかりにくいと感じたことを認めました。 比較のために、ApigeeとAzure API Managementの論理アーキテクチャを示します。







ご覧のとおり、Azure API Managementアーキテクチャはよりシンプルです。 オブジェクトが少ない。 したがって、管理者とユーザーの両方にとって理解しやすいです。

3.意思決定のアーキテクチャ

ソリューションのアーキテクチャは次のようになります。





3.1。 すべての中心にあるのは、IDおよびサブスクリプション管理（EM）システムです。

彼女は次のオブジェクトを操作します。

• 組織とそのユーザー（認証）。
• API製品を含む、サブスクリプションの製品カタログ。
• サブスクリプション（承認）-ユーザーと製品の関係。

3.2。 ユーザーは、ポータルインターフェイス（EM Webフロント）を介して対話します。 Azure API Managementは、APIスイートへのアクセスを制御します。

主なオブジェクトは次のとおりです。

• APIは、APIを表す論理エンティティです。
• ポリシー-APIの使用に関する制限。 たとえば、1か月あたりのリクエスト数や転送されたデータの量。
• ユーザー-最も一般的なケースでは、アプリケーションでAPIを使用するのは開発者です。
• サブスクリプション-製品とユーザーのバンドル。

Azure管理API-技術面では、ユーザーに提示され、アプリケーションを考慮して、バックエンド側の対応するAPIに呼び出しをリダイレクトするWEBプロキシです。



3.3。 APIMブロックを使用すると、EMのユーザーとAzureのユーザーをシームレスにマッピングできます。



3.4。 ユニバーサル支払い処理ユニットである「支払い」が個別に強調表示されており、これまでのところ定期支払い（定期支払い）をサポートしています。 PayPalとのみ統合されていますが。 将来的には、Apple PayとGoogle Payをここで接続する予定です。



その結果、ユーザーは一度にポータルにいます。

• 14種類のAPI製品すべてをカバーする3つのセットから1つを選択し、
• 1か月あたりのリクエストの許容頻度とリクエストの合計制限を決定する関税を選択します。
• 支払いに進みます。

リアルタイムのサブスクリプション管理システムは、支払いデータを受け取り、アクセスを有効にします。



組織のユーザーと開発者は、APIの使用に関するドキュメントとサンプルがある開発者ポータルにアクセスできます。

4.いつカスタムオートメーションが必要ですか？

正直に言ってください-実際のビジネスと会うときの「既製」のプラットフォームは通常、改善が必要です。 「すぐに使える」機能は、ビジネスアイデアをテストするために使用できる、また使用する必要があるすべての必要な基本ツールを提供します。



ユーザーはほとんどいませんが、衣装を変更せずに製品を箱から取り出して、APIへのアクセスを手動で制御できます。

原則として、すべての手順は十分に明確です。

1. Azure API ManagementとEMシステムのユーザーリストを同期します。
2. EMの製品とAzure Management APIの対応する製品を同期します。
3. EMポータルで、PayPalへのリンクを作成してサブスクリプションを購入します。
4. PayPalからメッセージを受信すると、EMシステムでのサブスクリプションと、Azure Management APIでの対応するサブスクリプションが開始されます。
5. サブスクリプションの有効期限が切れると、支払いが行われていない場合、Azure APIおよびEMシステムのサブスクリプションからユーザーが削除されます。

この場合、Azure API Managementを提供するためのサブスクリプションスキームは非常に便利です。APIManagementシステムと統合に多額の資金を投じることなく、コンセプトをテストできます。



そして、より多くのユーザーがいるとします。 私たちのクライアントには4000人以上のアクティブな加入者がいます。 ご理解のとおり、アクセスを同期および提供/無効化するための手作業の量は率直に高くなります。 ただし、APIへのアクセス権の販売からより多くの資金を受け取り、これらの手順の自動化に投資できるようになりました。

• Azure API Managementのユーザーリストを同期する委任メカニズムがあります。 開発者ポータルに入ると、ユーザーをポータルにリダイレクトし、そこからユーザーが既に許可された場所に戻ることができます。 詳細については、 azure.microsoft.com / en-en / documentation / articles / api-management-howto-setup-delegationで説明しています。
• 次に、Azure API Managementの製品をシステムのEMカタログの製品にマップできる特別なサービスを作成します。
• 手動モードと同様に、EMポータルでPayPal Webサイトにリダイレクトして、サブスクリプションを購入します。 ここでは、定期的な支払いの可能性を設定します。
• 次のタスクは、支払い時にサブスクリプションを取得することです。 PayPal-EMシステムで、サービスの呼び出しの形で支払い確認の通知を送信できます。 このサービスは、開始し、EMにサブスクライブし、Azure API Managementの変更を変換します。 対応するメッセージハンドラーは、Azure API Management Rest APIを使用してサインアップします： msdn.microsoft.com/en-us/library/azure/dn776325.aspx
• 最後に、サブスクリプションの有効期限が切れた後、ユーザーを削除する必要があります。 これを行うために、EMシステムでは、有効期限属性をサブスクリプションに追加しました。 そして、EMでサブスクリプションの有効期限を定期的に確認し、Azure API ManagementへのアクセスをブロックするJOBを作成するだけです。

5.合計

APIサービスへの有料アクセスを提供するかどうかを検討している場合、Azure API Managementサブスクリプションスキームを使用すると、資本投資なしでビジネスコンセプトをすばやく確認できます。



APIに十分な需要があることがわかった場合、Azure API Managementに基づいたカスタムソリューションを使用すると、以下を提供できます。

• 管理のしやすさ。 Azure APIMプラットフォームアーキテクチャにより、APIをできるだけ簡単に管理できます。
• サーバー部分とポータルの深い統合。
• 顧客にとって便利な外部支払いシステムとの柔軟な統合。
• そして、もちろん、有料のAPIプロビジョニングの費用対効果。 私たちの場合、Masheryと比較して、コンスタントボーンは10倍減少しました！ はい、プロジェクトの開発に一時的な費用がかかりました。 そして、クライアントは、各操作に対して支払いシステムに料金を支払います。 しかし、これは利益のコストです。 ついに登場しました。