深入探讨API主导架构方法及实现模式

随着 API 开放信息和功能的大门，它们已超越单纯的技术接口，成为新数字业务模型的核心。为了使这些业务模型有效且成功，技术团队面临着支持 API 的独特挑战，而这些系统并不一定是为了提供实时访问而构建的。因此，必须满足多种实现要求，以创建易于使用且能真正扩展以处理实时系统所需数量的 API。

本文摘自 Luis Weir 撰写的《企业 API 管理》一书，探讨了成功企业 API 的架构决策、实施模式和管理实践，并详细阐述了实现 API 主导架构所需的核心概念和功能。

API 主导的架构方法将 API 置于应用程序与其需要访问的业务功能之间，以在所有数字渠道上一致地提供无缝功能。例如，API 网关可以提供对不同业务功能的 API 的访问。

此外，由于 API 可以直接或间接推动创收，提供 API 的部门可以从成本中心转变为潜在的利润中心。换句话说，API 成为一流的商业公民，而非企业对集成的常见看法中的“不可避免的罪恶”。简而言之，API 本身成为产品，因此需要与其他业务产品相同水平的设计思维、持续关注和发展。

以 API 为主导的架构

API 被比作门，用以阐明其在提供对企业信息资产和业务能力的访问中的作用。然而，门的类型、材料和尺寸各异，API 也可分为不同类型。

某些 API 在构建时专注于特定用例和应用程序，因此可高度专业化，并根据其服务目的进行定制。这类 API 的用途单一，难以在其构建的上下文之外重用。

用于指代这些单一用途 API 的常用术语是体验 API，因其主要支持人类直接交互的应用程序（如移动应用程序和 Web 应用程序）。然而，并非所有需要专用 API 的应用程序都需与人类交互。例如，在工业 2.0 中，API 可用于支持现代工业线，或在农业领域，API 通过无人机扫描大面积土地的土壤状况，实现实时数据获取和发送。

另一些 API 则专为重用而构建，这类 API 更加通用，不绑定于特定用例，因此适用于多种场景。下图展示了多种应用程序如何使用通用 API 来满足不同的用例需求。

了解不同类型的 API 是构建 API 主导解决方案的基础，强大的架构必须深入理解相关业务领域及所需功能。在企业级 API 的背景下，API 主导架构应解决以下核心问题：

保护 API 免遭未经授权的访问和重大安全威胁
确保消费应用程序能找到正确的 API 端点
限制对 API 的调用次数以确保持续可用性
支撑能力包括 API 设计、测试、持续集成、生命周期管理、监控和运维
错误处理以防止错误在堆栈中传播
通过丰富的分析和洞察进行实时监控
支持灵活的业务功能，如微服务架构

后续部分将介绍一种自顶向下的方法来阐述 API 主导架构，首先从概念上定义架构的核心构建块及其目的，接着详细描述实现这些目的所需的功能，最后说明这些功能如何作为一个模块化平台紧密结合在一起。

概念架构视图

以 API 为主导的概念视图定义了架构的主要构建块及其目的和职责。如图 3 所示，概念性 API 主导架构由四个主要构建块和消费应用程序组成。水平块代表核心运行时功能，这些功能是实现 API 的基础；垂直块则代表生命周期支持、管理、运营和分析的重要支撑能力。

消费应用程序指能够调用和使用 API 的任何计算机程序。这些应用程序的类型多样，从传统的商业现成应用程序（如商务系统）到网络应用程序、移动应用程序、可穿戴设备，甚至更复杂的设备，如无人机和智能汽车。

API Exposure 构建块负责安全可靠地公开对 API 端点的访问。

服务是提供明确定义和有限功能的软件单元，这些功能被称为业务能力，因其对业务的重要性而得名。服务的功能可映射到业务流程，需实现业务逻辑、数据转换、验证、业务规则和编排等。服务通过 API 端点公开其功能，这些端点并不直接访问，而是通过 API 公开层进行中介。

管理和运营块包含支持 API 端到端生命周期管理的功能，包括 API 设计和模拟、策略实施、部署、升级、运行时操作，以及分析、弃用和更新。以开发人员为中心的功能（如 API 页面、开发人员门户和应用程序密钥管理）也是该构建块的一部分。这些构建块在 API 货币化时起到辅助作用，负责收集根据使用情况计费所需的重要指标。

最后，身份和访问块支持用户、角色和访问管理功能。从生命周期和运营的角度，该块使不同用户（如 API 产品所有者、管理员、设计者和开发人员）能够无缝登录到 API 管理控制台和/或开发人员门户，并根据角色限制对不同区域的访问。此块还通过生成和执行令牌（如 OAuth 2.0、OpenID 和 SAML）来支持身份验证和授权策略。