什么是 API？

API 是应用编程接口的缩写，它是指用于构建和集成应用软件的一组定义和协议。

借助 API，您无需了解实施原理，即可让您的产品或服务与其他产品和服务进行通信。这可以简化应用开发，从而节省时间和资金。无论您是在设计新工具和产品，还是管理现有工具和产品，API 都能为您提供灵活性；简化设计、管理和使用流程；并提供创新机会。

API 有时被视为一种契约，其文档代表了各方之间的协议：如果一方以特定方式发送远程请求，另一方的软件就会以相应的方式作出响应。

由于 API 简化了开发人员将新应用组件集成到现有架构中的方式，它们有助于业务和 IT 团队之间的协作。面对瞬息万变的数字市场，业务需求往往变化迅速——在这样的市场环境下，新的竞争对手仅凭一款新应用就可能改变整个行业。为了保持竞争力，支持创新型服务的快速开发和部署非常重要。云原生应用开发是一种明确有效的提升开发速度的方式，它依赖于通过 API 连接微服务应用架构。

API 是通过云原生应用开发连接您自己的基础架构的一种简便方式，但也允许您与客户及其他外部用户共享数据。公共 API 具有独特的商业价值，因为它们不仅能简化和扩展您与合作伙伴的连接方式，还有可能通过您的数据变现（Google Maps API 就是一个广为人知的例子）。

例如，假设有一家图书分销公司。该图书分销商可以为客户提供一个云应用，让书店店员能够查询分销商的图书库存情况。这款应用的开发成本可能较为高昂，受限于特定平台，且需要较长的开发周期和持续的维护。

或者，图书分销商可以提供一个用于查询库存情况的 API。这种方法有以下几个好处：

• 让客户通过 API 访问数据，有助于他们将库存信息汇总到一个位置。
• 只要 API 的行为不发生变化，图书分销商就可以在不影响客户的情况下对其内部系统进行更改。
• 借助公开可用的 API，为图书分销商、图书销售商或第三方工作的开发人员可以开发一款应用，帮助客户查找所需的图书。这可能会带来更高的销售额或其他商业机会。

简而言之，API 让您能够在保持安全性和控制力的同时，开放资源访问权限。如何开放以及向谁开放访问权限，完全由您决定。API 安全防护的核心在于良好的 API 管理，其中包括使用 API 网关。通过一个能够连接一切（包括遗留系统和物联网（IoT））的分布式集成平台，可以连接到 API，并开发利用 API 提供的数据或功能的应用。

通过向合作伙伴或公众公开您的 API，可以：

• 开辟新的收入渠道或拓展现有收入渠道。
• 扩大品牌影响力。
• 通过外部开发和协作，促进开放创新或提高效率。

听起来很棒，对吧？但是，API 究竟如何实现这一切呢？

让我们回到图书分销公司的例子。

假设该公司的某位合作伙伴开发了一款应用，帮助人们查找书店书架上的图书。这样一来，客户体验得到了提升，吸引了更多购物者光顾书店（即分销商的客户），并拓宽了现有的收入渠道。

也许某个第三方使用公共 API 开发了一款应用，让人们可以直接从分销商那里购买图书，而不是从商店购买。这为图书分销商开辟了一条新的收入渠道。

无论是与特定合作伙伴，还是与全世界共享 API，都会产生积极影响。每一种合作伙伴关系，都能让您的品牌认知度超越公司自身营销努力所能达到的范围。像公共 API 那样对所有人开放技术，可以鼓励开发人员围绕您的 API 构建应用生态系统。使用您技术的人越多，就越有可能有更多人与您开展业务。

将技术公开，可能会带来全新且意想不到的成果。这些结果有时甚至会颠覆整个行业。对于我们的图书发行公司来说，新的业务（例如图书借阅服务）可能会从根本上改变他们的业务运营方式。借助合作伙伴 API 和公共 API，您可以利用比内部开发人员团队规模更大社区的创造性成果。新想法可能来自任何地方，公司需要敏锐察觉市场变化，并随时准备好采取行动。API 可以助您一臂之力。

API 诞生于计算机发展的早期阶段，远在个人计算机问世之前。当时，API 通常被用作操作系统的库。尽管 API 有时会在大型机之间传递消息，但几乎只能在它所运行的系统本地使用。近 30 年后，API 突破了本地环境的限制。到 21 世纪初，API 已成为实现数据远程集成的一项重要技术。

远程 API 旨在通过通信网络进行交互。所谓远程，是指 API 操作的资源位于发出请求的计算机之外。由于互联网是最广泛使用的通信网络，因此大多数 API 都是基于 Web 标准设计的。并非所有远程 API 都是 Web API，但可以合理地认为 Web API 属于远程 API。

Web API 通常使用 HTTP 作为请求消息协议，并提供响应消息结构的定义。这些响应消息通常以 XML 或 JSON 文件的形式呈现。XML 和 JSON 均为首选格式，因为它们以便于其他应用处理的方式呈现数据。

随着 Web API 的普及，协议规范应运而生，以帮助标准化信息交换：简单对象访问协议，通常称为 SOAP。采用 SOAP 设计的 API 使用 XML 作为消息格式，并通过 HTTP 或 SMTP 接收请求。SOAP 使运行在不同环境中或以不同语言编写的应用更容易共享信息。

另一种规范是表述性状态转移（REST）。遵循 REST 架构约束的 Web API 被称为 RESTful API。REST 与 SOAP 存在根本区别：SOAP 是一种协议，而 REST 是一种架构风格。这意味着 RESTful Web API 没有官方标准。正如 Roy Fielding 在其论文“Architectural Styles and the Design of Network-based Software Architectures”（《架构风格与基于网络的软件架构设计》）中所定义的那样，只要 API 符合 RESTful 系统的六项指导性约束，就属于 RESTful API：

• 客户端-服务器架构：REST 架构由客户端、服务器和资源组成，通过 HTTP 处理请求。
• 无状态性：在两次请求之间，服务器上不会存储任何客户端内容。会话状态的相关信息由客户端保存。
• 可缓存性：缓存可以消除部分客户端与服务器之间交互的需求。
• 分层系统：客户端与服务器的交互可以通过额外的层来中转处理。这些层可以提供额外的功能，如负载均衡、共享缓存或安全防护。
• 按需提供代码（可选）：服务器可以通过传输可执行代码来扩展客户端的功能。
• 统一接口：这一约束是 RESTful API 设计的核心，包括四个方面：
  • 请求中的资源标识：资源在请求中被标识，并与返回给客户端的表示形式相互独立。
  • 通过表示形式来操作资源：客户端接收代表资源的文件。这些表示形式必须包含足够的信息，以便进行修改或删除操作。
  • 自描述消息：返回给客户端的每条消息都包含足够的信息，用于描述客户端应如何处理这些信息。
  • 超媒体作为应用状态的引擎：访问资源后，REST 客户端应能够通过超链接发现当前可用的所有其他操作。

这些限制看似很多，但实际上比预先规定的协议要简单得多。正因如此，RESTful API 正逐渐取代 SOAP 成为主流。

近年来，OpenAPI 规范已成为定义 REST API 的通用标准。OpenAPI 为开发人员提供了一种与语言无关的方式来构建 REST API 接口，使用户能够以最少的猜测理解这些接口。

另一项新兴的 API 标准是 GraphQL，这是一种可替代 REST 的查询语言和服务器端运行时。GraphQL 优先考虑向客户端提供所请求的数据，绝不提供多余信息。作为 REST 的替代方案，GraphQL 允许开发人员构建请求，通过单次 API 调用从多个数据源提取数据。

了解有关 SOAP 与 REST 的更多信息

最常使用远程 API 的两种架构方法是：面向服务的架构（SOA）和微服务架构。在这两种方法中，SOA 出现最早，它最初旨在改进单体式应用。一个单体式应用可包揽所有功能；而在 SOA 中，部分功能可以由不同的应用来提供，这些应用通过某种集成模式（例如企业服务总线（ESB））实现松散耦合。

虽然 SOA 在大多数方面比单体式架构更简单，但如果对组件之间的交互缺乏清晰理解，就可能导致整个环境中出现连锁变更的风险。这种额外的复杂性又重新引入了 SOA 原本试图解决的一些问题。

微服务架构在使用专门的松散耦合服务方面与 SOA 模式类似，但在打破传统架构方面走得更远。微服务架构中的服务使用通用消息传递框架，例如 RESTful API。它们利用 RESTful API 相互通信，无需复杂的数据转换操作或额外的集成层。使用 RESTful API，不仅能够实现，甚至还能促进新功能和更新的快速交付。每项服务都是独立的。可以替换、增强或移除某项服务，而不会影响架构中的任何其他服务。这种轻量级架构有助于优化分布式或云资源，并支持单个服务的动态可扩展性。

了解有关 SOA 的更多信息

Webhook 是一种基于 HTTP 的回调函数，可实现两个 API 之间轻量级、事件驱动的通信。许多 Web 应用都使用 Webhook 来接收来自其他应用的少量数据，但 Webhook 也可用于在 GitOps 环境中触发自动化工作流。

Webhook 通常被称为“反向 API”或“推送 API”，因为它们将通信的责任交由服务器承担，而非客户端。与客户端不断发送 HTTP 请求来请求数据，直至服务器作出响应的方式不同，服务器在数据可用时会立即向客户端发送一个 HTTP POST 请求。虽然有这些别名，但其实 Webhook 并非 API，二者可以结合使用。应用必须具有 API 才能使用 Webhook。 

进一步了解 Webhook

模型上下文协议（MCP）和 API 都充当了数字桥梁，使独立的系统之间能够相互连接。MCP 的能力基于 API 构建而成，如果没有 API，MCP 便无从谈起。 

这两项技术在运作方式和服务目标上有所不同：

• MCP 将语言模型与外部工具和数据相连接，从而支持能够实时适应和灵活调整的工作流。 
• 传统的 API 工作流遵循一套固定的规则。两个系统连接后，交互仅限于开发人员预先编程的一组特定操作。

进一步了解 MCP 与 API