新的好朋友：API 和集成

在一些公司，API 已经在集成团队的工具包中占据了重要位置。然而，也有一些公司似乎从未听说过 API。没关系，只要没有任何活动需要应用程序接口。例如，使用应用程序接口的需求可能来自于：

有备无患

由于上面提到的一些问题可能会在短时间内成为现实，因此现在就应该开始准备，其中可能涉及以下主题：

这些步骤做得越多，当出现 API 需求时，实施起来就越快越容易。

理想情况下，这些准备工作应该做到能够证明潜在的应用程序接口请求是合理的，而不是主动推动应用程序接口的使用。

市场上有各种解决方案，大致可分为以下几种：

纯粹的应用程序接口解决方案不提供经典的集成技术，或仅通过扩展提供这些技术，而 “一体化 “解决方案则将所有技术整合到一个平台上，实现无缝互动。

而这正是许多公司面临的最大挑战。通常情况下，并非所有相关组件（如应用程序）都已与 API 兼容。有些组件由于成本过高或技术上不可行，永远无法实现 API 兼容。

只能为应用程序接口提供服务的集成解决方案将受到极大限制，甚至对某些任务毫无用处。纯粹的 API 解决方案本质上是另一个独立系统。

而将 API 活动与集成任务相结合的集成解决方案则能为您提供无限的功能。从本质上讲，应用程序接口可以被视为一种信封，您可以在其中装入任何想要的东西。

举几个例子：

应用程序接口与非应用程序接口兼容组件的交互提供了许多选择。同时，还需要考虑一些主题：

非 API 兼容组件的可用性

如果一项服务（如网站或智能手机应用程序）需要全天候可用，那么其底层组件也需要全天候可用。如果无法保证这一点，则应提供适当的错误信息（如 “尊敬的用户，由于维护原因，我们的服务目前不可用”，这比 “500 – 内部服务器错误 “等技术信息要好得多）。

非 API 兼容组件的性能

在应用程序接口内进行的任何活动都需要时间。这种时间会增加向应用程序接口发出的任何请求的响应时间。如果期望 API 的响应时间不超过 100 毫秒，而为 API 提供信息的后台系统的响应时间却达到 2 秒，那么这种期望就根本无法实现。您还需要检查多个并行调用是否会进一步减慢响应时间。

到目前为止，还没有出现从传统集成或 EDI 向应用程序接口转变的巨大浪潮。这可能是因为许多正在使用的接口已经非常成熟，而改变总是伴随着成本和风险。

尽管如此，通过集成和使用应用程序接口来创造价值的趋势在各个领域都非常明显，无论是其实时处理能力还是抽象、统一接口层的优势。

因此，对应用程序接口的明确建议是 “行动 “而不是 “反应”。这样，您就已经为每个 IT 部门迟早需要考虑的问题做好了准备。