统一 API：弥合 SaaS 应用程序之间的差距

统一应用程序编程接口 (API) 是一种充当抽象层的 API，可以同时与多个底层 API 进行通信。

因此，统一 API 中的每个对象和端点都会映射到底层API中相应的对象和端点。 这使得 SaaS 公司能够构建与统一 API 的单一集成，并立即发布与每个底层 API 的集成。

在本文中，我们将深入探讨统一 API、它们的工作原理、挑战和功能，以及它们如何使 SaaS 公司受益。

统一API解决什么问题？

SaaS 买家开始期望他们购买的解决方案能够实现无缝的本机集成。 互操作性不再是一种美好的东西，而是一种要求。 然而，与其他工具构建这些本机集成是当今每个 SaaS 公司都面临的挑战，因为它需要大量的工程资源来交付和维护。

对于每次集成，工程师都必须构建安全身份验证，梳理第三方应用程序的 API 文档，实现交付用例所需的业务逻辑，并为最终用户构建直观的配置体验。

这并没有考虑到在添加新功能请求时、第三方 API 发布重大更改时维护和更新集成所涉及的所有工作，以及开发人员帮助客户调试集成问题所花费的时间。

在SaaS 集成的背景下，近年来出现了统一 A​​PI，作为应对理解每个第三方应用程序 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 及其优点、挑战和用例的所有信息。