概念回顾： API 和 API 互联

作者：NGINX开源社区

2023-11-15
北京
本文字数：4558 字
阅读完需：约 15 分钟

原文作者：NGINX
原文链接：概念回顾： API 和 API 互联
转载来源：NGINX 开源社区

NGINX 唯一中文官方社区，尽在 nginx.org.cn

随着微服务架构的兴起，API 的数量急剧增加，由此也产生了一系列的挑战与解决方案。阅读本文，了解与 API 相关的基础概念以及 API 的使用现状。

什么是应用编程接口 (API)？

应用编程接口（简称 API）是一组定义、规则和协议，支持用户（人或软件）和信息（在线和 Web 应用提供的数据资源）两个实体之间的通信。

如今，API 构成了现代应用的基本框架，帮助改善用户体验并增强业务模式。有时，API 甚至自身可以作为一种业务模式。

API 的工作原理是什么？

API 是应用的“门面”，展示了应用执行的功能及其可提供的信息，并定义了正确的请求格式。当开发人员为一款应用创建 API 并将其暴露后，它允许其他应用与该应用通信。

在许多情况下，API 可帮助开发人员节省宝贵时间，因为它们让常用功能可以直接拿来使用。开发人员可通过调用现有应用的 API，将所需功能集成到自己的应用中，而不必浪费时间重新开发这些功能。

每个 API 的设计、部署和运行方式都取决于其架构风格或协议。

API 架构和协议的类型

API 架构或架构风格是指 API 的顶层设计，包括 API 的结构和组织方式及其请求/响应格式。API 协议不仅指定了格式，同时还描述了确切的消息。

常见的 API 架构和协议包括：

REST —— 也被称为 RESTful，这种架构风格基于表征状态转移的原则。它使用 HTTP 方法（例如 GET、POST、PUT 和 DELETE）和抽象信息（以资源和资源模型的形式）来创建可扩展、灵活且技术独立的结构。如今，REST 仍然是最受欢迎的 API 架构。

GraphQL —— 由 Meta（原名 Facebook）开发的一种开源查询语言，GraphQL 架构支持通过单个 API 调用从多个来源获取数据。由于客户端只请求必要的数据，因此 GraphQL API 往往比 REST API 更加高效（但缓存能力较差）。

SOAP —— 这种架构方法使用简单对象访问协议 (SOAP)。SOAP 消息通常采用 XML 格式，因此相比 REST 或 GraphQL 略显笨重。与 REST API 不同，SOAP API 采用严格的实施准则来定义 API 协议的结构。

WebSocket —— 这种 API 协议为全双工通信协议，意味着客户端和服务器可以同时发送和接收消息。此外，服务器发送的消息可以不是对客户端请求的响应，而是（例如）由服务器端的事件触发。相比之下，REST API 遵循严格的“请求-响应”模式。

RPC —— 借助远程过程调用，开发人员能够使用相同的代码来调用在不同地址空间（通常是在远程服务器上）中运行的函数 — 就像调用本地函数一样，而不必指定远程交互的细节。由于可以使用多种语言，因此这种协议很灵活，常用于“客户端-服务器”通信。gRPC（Google 远程过程调用）就是一种 RPC。

API 使用现状

API 是现代软件的关键组成部分，如今各企业都会根据需求构建或使用许多不同类型的 API。

目前企业中最常见的四种 API 是公共 API、私有 API、合作伙伴 API 和第三方 API。

公共 API

公共 API 可供企业外部的用户访问（无论是付费还是免费），助力您与第三方开发人员建立合作伙伴关系并扩展整个业务生态系统。

由于公共 API 可被第三方开发人员用来构建新产品，因此有助于推动创新，是帮助建立新合作伙伴关系的重要工具。

私有 API

私有 API 仅可供企业内部的团队访问，不仅能够帮助您解锁数据并促进内部协作，而且还可为企业面向公众的应用（例如您的网站）提供无形的支持。

由于私有 API 仅供内部用户使用，因此企业可以在构建时充分考虑优化问题。私有 API 还提升了现代应用的可组合性，支持企业根据当前的需求进行调整。开发人员可以在构建微服务时轻松集成私有 API，从而减少团队间的重复工作。

合作伙伴 API

合作伙伴 API 用于直接集成业务合作伙伴解决方案（例如，当一家航空公司与一家连锁酒店合作时，您可以机票和酒店同订）。合作伙伴 API 不公开提供 — 只有满足两家企业的身份验证 (AuthN) 和授权 (AuthZ) 要求的部分开发人员才可对其进行访问。

互操作性加强了与合作伙伴 API 的关系，因为它们打破了孤岛，支持不同企业相互通信。

第三方 API

第三方 API 可被企业用于访问应用和服务中缺少的数据或功能。这些 API 在第三方服务器上运行，通常提供广泛需要的服务（例如许多电子商务网站使用的 Stripe 支付处理 API）。这些 API 可供企业付费或免费使用，具体视 API 而定。

由于第三方 API 均由其他开发人员或企业构建，因此可显著节省成本。此外，第三方 API 是企业加快应用开发的一个重要途径，因为开发人员可以立即使用所需功能，无需自行编写。

使用哪些应用语言来创建 API？

几乎任何现代编程语言都可以用来编码 API。在编码 API 时，许多开发人员可能会选择使用一个框架。框架提供了代码库等构建块及其他必要实用程序，有助于更快速、更轻松地使用该语言构建应用。

每种编程语言一般都有一个或多个开发人员常用的框架。下表列出了几个框架选项（其中许多为开源框架）。

具体选择哪种语言和框架通常取决于项目需求或开发人员的个人偏好。

API 示例

API 是现代软件开发的一个基本组成部分，其示例不胜枚举。此处，我们只举数例。

三个 API 示例：

Google Maps Platform —— Google 提供的一个 API，支持您将 Google Maps 嵌入到网站或应用中。

AWS IoT —— AWS IoT API 支持您将物联网上的设备（例如智能家居设备）连接到 AWS 云。这是智能家居自动化系统的一种构建方式。

NGINX Unit Control API —— Unit API 使用 REST 架构来配置开源 NGINX Unit 应用和 Web 服务器。

什么是 API 策略？

企业需要根据其业务目标来制定现代 API 策略，后者为企业如何设计、开发、管理、治理和保护其 API 设定了方案。

根据 Gartner《适用于软件工程领导者的五大 API 经验教训》，现有五个最佳实践可帮助您确保实施强大的 API 策略：

切勿让 API 治理造成瓶颈。需要在 API 治理与开发人员敏捷性之间取得平衡，以不断推动创新。

将 API 视为产品，即使您不打算从中盈利。确保每个 API 都有明确的用途和受众，与业务目标相匹配。

先于黑客发现自己的 API。重视可发现性和定期监控有助于防范安全漏洞。

管理 API 的生命周期。全面的 API 生命周期管理可确保 API 在适当的安全防护下持续运行。

选择最适合的 API 技术。适合其他企业的技术不一定适合您，因此您必须详细考虑您当前和未来的具体 API 需求。

无论您选择哪种类型的 API 架构或者正在编写哪种类型的 API，必须从一开始就考虑 API 安全防护，而非事后弥补。

什么是 API 互联？

“API 互联”是指在云原生环境中使用模块化、可复用的 API 来连接数据和应用。与侧重于管理单个 API 生命周期的 API 管理不同，API 互联涉及松散耦合的微服务环境（其中许多 API 相互通信），并支持在这些架构中大规模保护和治理 API。

虽然 API 曾仅仅被视为开发人员的工具，但现已成为战略业务资产，不仅有助于创收，而且还支持企业敏捷性。随着各企业不断创新并纷纷采用 API，这给可视化、安全防护和治理提出了新的挑战。企业需要使用新型 API 互联解决方案，以完善传统和微服务架构，与 DevOps 实践保持一致，并支持高性能 API。

API 类型和 API 互联体验

过去，全生命周期 API 管理解决方案主要用于管理内部或外部 API 的南北向流量（客户端到后端）。现在，随着云原生基础架构不断生成更多的东西向流量（在企业应用基础架构内的微服务之间），API 的类型也有所增加。

目前，大多数企业使用四种类型的 API：

内部 API — 仅暴露给企业内的其他应用（及其开发人员），而不暴露给外部用户。内部 API 有助于解锁数据并促进企业内各职能部门之间的协作。

外部 API — 暴露给企业外部的用户。外部 API 支持与第三方开发人员和您的整个业务生态系统建立合作伙伴关系，并可成为收入来源。

合作伙伴 API — 暴露给业务合作伙伴。这些 API 不会公开 — 只有满足两家企业的身份验证 (AuthN) 和授权 (AuthZ) 要求的部分开发人员才可对其进行访问。

第三方 API — 由第三方暴露并位于其服务器上。这些 API 通常用于提供广泛需要的服务（如地图），并专门开发供其他公司使用，一般是收费的。

API 互联的其他关键要素包括 API 网关（反向代理或 Ingress controller）和 API 开发人员门户。API 网关接受来自客户端的 API 请求，将其定向到相应的 service，并将请求结果融入用户的同步体验中。开发人员门户是一个在线平台，您可以在此发布有助于 API 消费者快速入门的资源，例如外部 API 的目录、完备的文档及示例代码。它还允许第三方开发人员注册其应用，并获得 API 访问凭证。

多云的挑战

如今，API 和微服务都将被部署在多个环境中 — 公有云、私有云、本地和边缘。随着微服务日益成为高流量公司扩展应用的关键工具，内部 API 流量也大幅增加。

在复杂的多云环境中，API 端点（endpoint）激增，因此需要采用一种新的 API 管理、治理和安全防护方法。这些分布式环境需要低接触的自动化方法来为开发人员赋能，并支持平台运维团队跨不同的业务线设置安全防护和资源防护。

确保多云架构的可靠性和安全防护给平台运维团队带来了严峻的挑战。他们需要全面了解应用和 API 流量，并能够跨不同环境应用一致的安全防护和合规策略。平台原生工具的操作方式各不相同，提供了不同程度的可视性和控制力。最终，平台运维团队需要使用其他模型来跨分布式团队和环境创建并应用治理规则。

API 治理有两种常见模型 — 集中式和分散式。但在现代 API 策略中，尤其是在 API 优先模型中，“自适应治理”的新理念可为 API 开发人员赋能，同时为平台运维团队提供可靠性和安全防护控制能力。

如欲了解更多信息，请阅读我们的博文《自适应治理可为 API 开发人员提供其所需的自主权》。

API 优先工具的重要性

云原生环境是松散耦合的系统，通常使用容器、service mesh（服务网格）和微服务构建而成。上述资源通过 API 相互通信，并通常通过声明性 API 进行自主管理。这些技术能够构建容错性好、易于管理和便于观察的系统。

API 互联强调使用云原生技术，特别是使用 API 优先方法来管理基础架构和 API 生命周期。这对于使用持续集成/持续交付 (CI/CD) 实践实现大规模自动化运行尤为重要。CI/CD 可通过自动化功能帮助您在 API 和应用的整个生命周期（编写、交付和更新）对其进行高效管理。它还支持在早期集成并嵌入安全策略，然后将其应用于未来 API，助力实现“安全左移”，让安全防护融入整个开发流程，直至投入生产环境。

API 互联和 API 主导的互联策略之间有何区别？

“API 主导的互联”是实现数字化转型和企业整体 API 策略的特定架构方法。它使用分层的方法按功能对企业的 API 进行分类：

系统 API 用于从记录系统中获取原始数据，并通过一种可靠的方式将其暴露给上游 API

流程 API 可编排多个下游系统 API，以汇总数据并将业务逻辑应用于数据

体验 API 支持面向用户的交互，并可在移动和 Web 应用中重复使用

无论您使用何种架构模式对 API 进行分类，API 互联都是一种在云原生环境中治理和操作 API 的综合方法。