統合 API: SaaS アプリケーション間のギャップを埋める

統合アプリケーション プログラミング インターフェイス (API) は、複数の基礎となる API と同時に通信できる抽象化レイヤーとして機能する API です。

その結果、統合 API の各オブジェクトとエンドポイントは、基礎となるAPIの対応するオブジェクトとエンドポイントにマップされます。 これにより、SaaS 企業は統合 API との単一の統合を構築し、基盤となる各 API との統合を即座に出荷できるようになります。

この記事では、統合 API、その仕組み、課題と機能、SaaS 企業にとってのメリットについて詳しく説明します。

統合 API はどのような問題を解決しますか?

SaaS 購入者は、購入するソリューションにシームレスなネイティブ統合を期待するようになりました。 相互運用性は、もはやあると嬉しいものではなく、要件です。 ただし、これらのネイティブ統合を他のツールと構築することは、出荷と保守に多大なエンジニアリング リソースを必要とするため、今日すべての SaaS 企業が直面している課題です。

すべての統合において、エンジニアは安全な認証を構築し、サードパーティ アプリの API ドキュメントを精査し、ユースケースを提供するために必要なビジネス ロジックを実装し、エンド ユーザー向けの直感的な構成エクスペリエンスを構築する必要があります。

また、これには、新しい機能リクエストが追加されたときの統合の維持と更新にかかる作業、サードパーティ API が重大な変更をリリースしたとき、および開発者が顧客の統合の問題のデバッグを支援するのに費やした時間がすべて考慮されているわけではありません。

SaaS 統合のコンテキスト内で、各サードパーティ アプリの API ドキュメントを理解するという課題に取り組む方法として、統合 API が近年登場しました。

これにより、エンジニアリング チームは、統合ごとに、個々の API のニュアンス、形状、命名法を常に学習したり、再検討したりする必要がなくなります。

統合 API はどのように機能しますか?

具体的な例を使用して、統合 API がどのように機能するかを見てみましょう。

顧客が製品を CRM と統合することを求めていると想像してください。ユーザー ベース全体で、Salesforce を使用する顧客もいれば、HubSpot を使用する顧客も、Dynamics や Pipedrive を使用する顧客もいます。

統合 CRM API は、基礎となる各 CRM の API への参照を維持することによって、これらの各 CRM の API を抽象化します。

出典:パラゴン

この例は、基礎となる各 CRM に「連絡先」を表すオブジェクトがあることを示しています。

HubSpot はこれをコンタクトと呼び、Salesforce はリードとコンタクトの両方のオブジェクトを提供し、Pipedrive はコンタクトをプロスペクトと呼びます。 統合 API 内の「Contact」オブジェクトへの呼び出しが行われると、統合 API は指定されたサービス内の対応するオブジェクトを参照します。

ここで、オブジェクト レベルの参照が最初の層ですが、これらのオブジェクト内には、抽象化されたプロパティまたはフィールドもあります。 上の例では、名前、ID、会社などの異なる命名法が含まれる可能性があります。

したがって、チームが複数の CRM 統合を構築している場合、理論的には、統合された CRM API を使用して単一の統合を構築し、基盤となるすべての CRM 統合を同時に出荷できるようになります。

カテゴリ固有の統合 API

さまざまな SaaS アプリケーションには独自のデータ モデル、構造、機能があるため、すべての API を 1 つの API に統合できるわけではありません。

したがって、ベンダーは一般に、CRM、会計、広告などの特定の SaaS 分野に固有の複数の統合 API を提供します。これらの SaaS アプリケーションは比較的類似したデータ構造を持ち、多くの共通のオブジェクトやプロパティを共有するためです。

統合 API を設計する場合、API プロバイダーは、統合 API に含める基礎となる API を慎重に選択する必要があります。これは、基礎となる API の重複が多いほど、統合 API が提供できる範囲が広くなるからです。

ただし、統合 API に互いに類似していないアプリケーションが含まれている場合は、基礎となる API が共有するすべてのオブジェクトとプロパティを表示できないため、あまり有用ではなくなります。 たとえば、CRM と会計アプリケーションを含む統合 API は、「顧客」オブジェクト以外のアプリケーションのデータ モデルの残りの部分とあまり重複しない可能性があるため、あまり役に立たない可能性があります。

統合 API の利点は何ですか?

統合 API は、多数の統合を出荷および維持する必要があるエンジニアリング チームに複数のメリットをもたらします。

API の抽象化

エンジニアリング チームは、各サービスの個別の API を学習して操作するのではなく、統合 API とのインターフェース方法を 1 回 (カテゴリごとに) 学習するだけで済みます。

これにより、これらの統合の構築がより簡単かつ迅速になるだけでなく、統合の複雑さも軽減されます。

さらに、メンテナンスに関しては、統合 API ベンダーが基盤となる API との通信を処理する責任を負います。つまり、チームは基盤となる API の 1 つに重大な変更が加えられることを心配する必要がありません。 最終的には、統合が確実に機能し続けるように、統合 API ベンダーが抽象化を更新する責任を負います。

マネージド認証

統合 API プロバイダーは通常、API キーまたは OAuth を介した場合でも、基盤となる API による認証の複雑さを抽象化するマネージド認証サービスを提供します。

複数の API と直接統合する場合は、ユーザー資格情報の管理や安全なトークン更新ポリシーの確保など、API ごとに認証プロセスを管理する必要があります。

各アプリケーションが認証を処理する方法には多くの微妙な違いがあるため、特に多数の API を使用している場合、これは面倒でエラーが発生しやすいタスクになる可能性があります。

ロギング

本来、統合 API はその基礎となる API に対してプロキシ リクエストを行います。 そのため、サードパーティのアプリケーションに対して行われたリクエストに関するデータを収集して分析します。 その結果、リクエストが失敗した場合、統合 API プロバイダーはこのイベントをログに記録し、基礎となる API から返されたエラー メッセージの詳細を提供できます。

このログ機能は、統合で発生する可能性のある問題を迅速に特定できるため、チームにとって役立ちます。 複数のサードパーティ API からのログを調べるのではなく、統合 API プロバイダーを利用してログ記録とエラー報告を一元化できます。

デバッグ エラーの場合、統合 API プロバイダーは、多くの場合、基礎となる API 自体よりも詳細なエラー メッセージを提供できます。 これは、エラー応答を分析し、問題の根本原因に関するより多くのコンテキストを提供できるため、エラーの診断に費やす時間を大幅に削減し、インシデントへの応答時間を短縮できるためです。

事前に構築されたユーザーインターフェイス

ほとんどの統合 API プロバイダーは、顧客が統合への認証を行うための事前構築されたインターフェイスを提供しているため、構成エクスペリエンスを自分で構築する必要がなくなります。

これにより、チームは各統合のユーザー エクスペリエンスを設計する手間が軽減されますが、統合 API 上で構築できる数十の統合の可能性を考慮すると、時間の節約がさらに悪化する可能性があります。

統合 API を使用する際の課題は何ですか?

統合 API は上記で共有した利点を提供しますが、企業が認識し始めているいくつかの構造的制限によって機能不全に陥っています。

ユースケースの制限

統合 API が基礎となる API 間で「共有」オブジェクトとエンドポイントのみを抽象化できることを考慮すると、すべての統合にわたって比較的シンプルで汎用化可能な機能のみを構築できます。 これは、あらゆる統合 API ソリューションにおける最大の制限です。

さらに、統合 API 内でサポートされるアプリケーションが増えるほど、制限が厳しくなります。

出典:パラゴン

これらの制限の例をいくつか見てみましょう。

相容れない特徴

統合の 1 つに固有の機能またはプロパティを含む統合機能を構築する必要がある場合、それは統合 API では不可能です。

たとえば、「統合フィードバック API」を介して複数の顧客フィードバック ツールと統合したいとします。 あるツールがフィードバック スコア 1 ～ 10 の定量モデルを活用しているのに対し、別のツールが「メモ」を伴う「否定的、中立的、肯定的」のみを収集する場合、調整ができないため、統合 API でこれらのユースケースをサポートできるわけがありません。それらを単一の参照にまとめます。

欠落しているフィールド

統合を通じて更新する必要があるプロパティが、サポートされている統合の特定のサブセットでのみ使用できる場合、そのプロパティは統合 API 内では使用できません。

たとえば、基盤となるサードパーティ アプリケーションのいくつかにフィールドとして郵便番号がある場合でも、そうでない限り、統合 API を介してプロパティとして郵便番号にアクセスすることはできません。

カスタムオブジェクトとフィールド

本来、統合 API は、基礎となる各 API への事前定義された参照のセットを提供します。 ただし、カスタム オブジェクトまたはフィールドを混合に導入すると、統合 API プロバイダーはそれらのオブジェクトまたはフィールドが何であるかを予測できません。 したがって、カスタム オブジェクトまたはフィールドを含む統合はサポートできません。

これは、サードパーティ アプリケーション内でのカスタム オブジェクトの使用をサポートするために提供する統合を顧客が必要とする場合、大きな障害となる可能性があります。

レート制限

統合 API を介して複数の API を一度に統合する場合は、各 API のレート制限を認識し、統合ロジックが 1 つの API の制限を超えないようにする必要があります。

これは、構築するロジックが、レート制限の最低しきい値を使用して API のレート制限に従う必要があることを意味します。 簡単に言うと、レート制限が最も低い API が統合の制限要因になります。 その API のエンドポイントに対してあまりに多くのリクエストを行おうとすると、たとえ統合 API 内の他の API が技術的に同じボリュームをサポートできたとしても、リクエストは失敗し始めます。

これらの統合の特定のエンドポイントに一括リクエストを行うときにレート制限エラーが発生しないようにするには、バッチ処理またはスロットリングを使用して、各 API に送信するリクエストのレートを制御する必要があります。

したがって、低いレート制限を回避することはまだ可能ですが、基盤となる統合のいずれかの制限に対応するために、コードベースにさらに複雑さを組み込むことになります。

安全

統合 API では通常、統合ごとに個別のスコープを選択できるのではなく、API を使用するためにサードパーティ サービスのすべてのスコープへのアクセスを承認する必要があります。

これは、統合を使用するユーザーを認証すると、そのユーザーは、統合に必要なデータだけでなく、そのサードパーティ サービスに関連付けられたすべてのデータへのアクセスを強制されることを意味します。

たとえば、統合 API を介して CRM 統合を構築しており、CRM は販売、マーケティング、およびカスタマー サポートのデータにアクセスできます。 ユーザーが統合を使用するために自分のアカウントを認証すると、アプリケーションに必要なのは売上データだけであっても、3 つのデータセットすべてにアクセスできるようになります。

これにより、顧客にセキュリティ上の懸念が生じる可能性があります。 こうした懸念を軽減するには、どのデータへのアクセスを要求しているのかをユーザーに対して透明性を保ち、そのデータが必要な理由を明確に説明することが重要です。

さらに、一般にベンダーが統合 API をホストしていることを考えると、ユーザーのデータを不正アクセスや侵害から保護するための強力なセキュリティ対策が講じられていることをベンダーに依存することになります。

独自のデータモデル

ベンダーがさまざまな基盤となる API と参照エンドポイントをどのように調整するかは、ベンダー独自の意見に依存します。 これはほとんどのユースケースでは問題になりませんが、場合によっては、同意できない抽象化、または期待される動作に従わない抽象化が表示される場合があります。

ロードマップの制約

多くのカテゴリにわたってあらゆるサードパーティ API を 1 対 1 で抽象化する組み込み統合プラットフォームと比較して、統合 API ベンダーは、統合 API を構築したカテゴリに限定されます。

時間の経過とともに新しい統合 API を構築することは可能ですが、現在サポートされていないカテゴリとの統合を要求した場合、その統合が利用可能になるまで何年も待たなければならない可能性があります。

唯一の例外は、ベンダーが、要求された統合が該当するカテゴリの統合 API を偶然構築している場合です。 それでも、SaaS エコシステムの広さとサポートできる潜在的なカテゴリを考慮すると、これが当てはまることはほとんどありません。

統合 API を使用する必要がある場合

統合 API がチームにとって適切なソリューションであるかどうかを判断する場合は、単純な意思決定基準に従うことができます。

上記の 4 つの点に自信を持って「はい」と言えない場合は、統合 API の使用に縛られたくないかもしれません。

代わりに、 組み込み統合プラットフォームは、統合開発プロセスの合理化に役立つより包括的なツールを提供しながら、より深い統合を構築できるため、より良いソリューションである可能性があります。

B2B SaaS 統合の課題

SaaS 製品のネイティブ統合ロードマップの拡張に役立つソリューションを決定するのは簡単ではありません。 現在のユースケースだけでなく、将来顧客が要求する可能性のあるすべてのユースケースにも対応できることを確認する必要があります。

顧客が必要とするユースケースが、特定のカテゴリ内のすべての統合にわたって均一である場合、統合 API は、最小限の労力で数十の統合を出荷するための優れたソリューションとなります。

これは多くの新規プレーヤーが存在する発展途上の市場であり、B2B SaaS 統合の課題を解決するための興味深いアプローチであることは確かです。

包括的なガイドで API、その利点、課題、ユースケースについてすべて学びましょう。