統一 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。

來源： Paragon

這裡的範例顯示每個底層 CRM 都有一個代表「聯絡人」的物件。

HubSpot 稱之為“聯絡人”，Salesforce 提供“潛在客戶”和“聯絡人”對象，而 Pipedrive 則將聯絡人稱為“潛在客戶”。 當呼叫統一API中的「聯絡人」物件時，統一API將引用指定服務中的對應物件。

現在，物件級參考是第一層，但在這些物件中，也存在抽象的屬性或欄位。 在上面的範例中，可能包括名稱、ID、公司等不同的術語。

因此，如果您的團隊正在建立多個 CRM 集成，理論上，您可以使用統一的 CRM API 建立單一集成，使您能夠同時交付所有底層 CRM 集成。

特定類別的統一 API

並非所有 API 都可以統一在一個 API 中，因為不同的 SaaS 應用程式具有獨特的資料模型、結構和功能。

因此，供應商通常會提供特定於某個 SaaS 垂直領域（例如 CRM、會計或廣告）的多個統一 API，因為這些 SaaS 應用程式將具有相對相似的資料結構並共享許多通用物件或屬性。

在設計統一API時，API提供者必須仔細選擇哪些底層API包含在統一API中，因為底層API的重疊越多，統一API可以提供的覆蓋範圍就越廣。

但是，如果統一 API 包含彼此不太相似的應用程序，那麼它的用處就會不大，因為它無法顯示底層 API 共享的所有物件和屬性。 例如，包含 CRM 和會計應用程式的統一 API 可能不是很有用，因為在「客戶」物件之外，其餘應用程式的資料模型之間可能沒有太多重疊。

統一API有什麼好處？

統一 API 為需要交付和維護數十個整合的工程團隊提供了多種好處。

API抽象

您的工程團隊無需學習每個服務的單獨 API 並與之交互，只需學習如何與統一 API 互動一次（每個類別）。

這不僅使建立這些整合變得更容易、更快，而且有助於降低整合的複雜性。

此外，在維護方面，統一 API 供應商負責處理與底層 API 的通信，這意味著您的團隊無需擔心對底層 API 之一進行重大更改。 最終，統一 API 供應商將負責更新其抽象，以確保整合繼續有效。

託管身份驗證

統一 API 提供者通常提供託管身分驗證服務，該服務抽象化了底層 API 驗證的複雜性，無論是透過 API 金鑰還是 OAuth。

當您直接與多個 API 整合時，您必須管理每個 API 的驗證流程，包括管理使用者憑證和確保安全的令牌刷新策略。

鑑於每個應用程式處理身份驗證的方式存在許多細微差別，這可能是一項繁瑣且容易出錯的任務，尤其是當您使用大量 API 時。

記錄

從本質上講，統一 API 會向其底層 API 發出代理請求。 因此，他們將收集和分析有關向第三方應用程式發出的請求的資料。 因此，當請求失敗時，統一 API 提供者可以記錄此事件並提供有關底層 API 傳回的錯誤訊息的詳細資訊。

此日誌記錄功能對您的團隊非常有用，因為它允許他們快速識別整合中可能出現的問題。 他們可以依靠統一的 API 提供者來集中日誌記錄和錯誤報告，而不是查看來自多個第三方 API 的日誌。

透過偵錯錯誤，統一的 API 提供者通常可以提供比底層 API 本身更詳細的錯誤訊息。 這是因為他們可以分析錯誤回應並提供有關問題根本原因的更多背景信息，這可以大大減少診斷錯誤所花費的時間並加快事件回應時間。

預先建置的使用者介面

大多數統一 API 提供者都會為您的客戶提供預先建置的接口，以進行整合式身份驗證，從而使您無需自行建立配置體驗。

這使您的團隊無需為每個整合設計使用者體驗，當考慮到您可以在統一 API 上建立的數十個潛在整合時，這可以進一步節省時間。

使用統一 API 面臨哪些挑戰？

雖然統一 API 提供了上述共享的好處，但它們受到一些公司開始越來越意識到的結構性限制的削弱。

用例限制

鑑於統一 API 只能抽象化底層 API 中的「共享」物件和端點，您只能建立相對簡單且可在所有整合中通用的功能。 這是迄今為止任何統一 API 解決方案的最大限制。

此外，統一 API 支援的應用程式越多，它的限制就越多。

來源： Paragon

讓我們來看看這些限制的一些範例。

不可調和的特點

如果您需要建立涉及特定於其中一個整合的功能或屬性的整合功能，則使用統一的 API 是不可能實現的。

例如，假設您希望透過「統一回饋 API」與多個客戶回饋工具整合。 如果一個工具利用回饋分數在 1-10 之間的定量模型，而另一個工具僅收集“負面、中立、正面”並附有“註釋”，則統一的 API 無法支援這些用例，因為您無法協調將它們合併為一個參考。

缺失字段

如果您需要透過整合更新的屬性僅適用於受支援整合的特定子集，則該屬性將不會在統一 API 中可用。

例如，即使少數底層第三方應用程式將郵政編碼作為字段，但只要有一個沒有，郵政編碼就無法透過統一API作為屬性進行存取。

自訂對象和字段

從本質上講，統一 API 為每個底層 API 提供了一組預先定義的參考。 但是，如果您將自訂物件或欄位引入其中，統一 API 提供者將無法預測這些物件或欄位是什麼。 因此，它們無法支援涉及自訂物件或欄位的整合。

如果您的客戶需要您提供的整合來支援在第三方應用程式中使用自訂對象，這可能會成為一個巨大的障礙。

速率限制

當您透過統一的 API 一次整合多個 API 時，您需要了解每個 API 的速率限制，並確保您的整合邏輯不會超出任何一個 API 的限制。

這意味著您建立的邏輯必須遵守具有最低速率限制閾值的 API 的速率限制。 簡而言之，速率限制最低的 API 將成為您整合的限制因素。 如果您嘗試向該 API 的端點發出太多請求，您的請求將開始失敗，即使統一 API 中的其他 API 在技術上可以支援相同的量。

為了避免在向這些整合的特定端點發出批次請求時遇到速率限制錯誤，您必須使用批次或限制來控制傳送到每個 API 的請求速率。

因此，雖然仍然可以解決較低的速率限制，但您會發現自己在程式碼庫中建立了額外的複雜性，以適應任何一種底層整合的限制。

安全

統一 API 通常要求您授權存取第三方服務的所有範圍才能使用其 API，而不是允許您為每個整合選擇單獨的範圍。

這意味著，當您對使用者進行身份驗證以使用您的整合時，該使用者將被迫向您授予與該第三方服務關聯的所有資料的存取權限，而不僅僅是整合所需的資料。

例如，您正在透過統一的 API 建立 CRM 集成，並且 CRM 可以存取銷售、行銷和客戶支援資料。 當用戶驗證其帳戶以使用您的整合時，您將有權存取所有三組數據，即使您的應用程式需要的只是銷售數據。

這可能會引起客戶的安全疑慮。 為了減輕這些擔憂，重要的是要對用戶公開您要求訪問哪些數據，並清楚地解釋為什麼您需要這些數據。

此外，考慮到供應商通常託管統一的 API，您需要依賴供應商來確保他們採取強有力的安全措施來保護您的用戶資料免遭未經授權的存取或洩露。

意見資料模型

供應商如何協調不同的底層 API 和參考端點取決於他們自己的意見。 雖然這對大多數用例來說不是問題，但有時它們可能會呈現您不同意的抽象，或不符合預期行為。

路線圖限制

與提供跨多個類別的每個第三方 API 的一對一抽象的嵌入式整合平台相比，統一 API 供應商僅限於他們為其建立統一 API 的類別。

雖然他們可以並且將會隨著時間的推移構建新的統一 API，但如果您要求與當前不受支援的類別集成，您很可能需要等待數年才能提供該集成。

唯一的例外是，如果供應商碰巧正在為所要求的整合所屬的類別建立統一的 API。 儘管如此，考慮到 SaaS 生態系統的廣度及其可以支持的潛在類別，這種情況很少發生。

什麼時候應該使用統一的 API

在決定統一 API 是否是適合您團隊的解決方案時，您可以遵循簡單的決策標準。

如果您不能自信地對上述四點說“是”，那麼您可能不希望局限於使用統一的 API。

相反，一個 嵌入式集成平台可能是更好的解決方案，因為它們使您能夠建立更深入的集成，同時提供更全面的工具來幫助簡化集成開發流程。

B2B SaaS 整合挑戰

決定一種解決方案來幫助您擴展 SaaS 產品的本機整合路線圖並不是一件容易的事。 您不僅必須確保它可以滿足您當前的用例，而且還可以滿足您的客戶將來可能要求的所有可能的用例。

統一 API 可以成為以最少的工作量交付數十個整合的絕佳解決方案，前提是您的客戶所需的用例在給定類別內的每個整合中都是統一的。

這是一個發展中的市場，有許多新參與者，當然也是解決 B2B SaaS 整合挑戰的有趣的方法。

在綜合指南中了解有關 API 及其優點、挑戰和用例的所有資訊。