PI 这一术语代表应用程序编程接口。在本书中，我们聚焦于一种特定类型的 API——即基于网络的 API。阅读完 API 的历史介绍后，你将看到本书所涵盖的 API 概览。我们将基于定义 API 风格的特征，对这些 API 进行比较。
除了不同 API 风格之间的差异外，你还将学习所有基于网络的 API 共有的概念。你将了解为什么要创建 API，包括将它们作为产品进行管理和变现的原因。你还会了解创建 API 的软件开发生命周期（SDLC）流程，以及 API 的治理和管理。理解这些内容将帮助你识别出最符合你需求的 API。
在探讨本书具体介绍的 API 之前，让我们先来看一下 API 的概念及其发展历史。
什么是 API？
“应用程序编程接口”中的“接口”一词，指的是实体之间进行交互的接触点。实体可以是用户、系统或组织等。
图 1-1 展示了一个实体与实体之间接口的示例。图中是一张电子显微镜拍摄的针头与黑胶唱片的图片。针头与黑胶唱片表面相接触。唱片上的沟槽是声音波形的物理刻印。一个力作用于针头，使其保持在沟槽中，当黑胶唱片转动时，针头的作用就能被听到。
以下是一些你可能每天都会接触到的接口示例：
人机接口设备（HID）
允许人们与其他设备进行交互和控制的设备，比如电视遥控器或电脑鼠标。
命令行接口（CLI）
通过文本命令行接收用户命令，并将这些命令传递给计算机系统的接口。
图形用户界面（GUI）
允许用户通过图形图标与计算机系统交互的接口。
聊天接口
暴露一个应用程序，使你能够进行类似聊天的对话的接口。
脑机接口（BCI）
一种允许大脑与外部设备之间直接通信的接口，又称为脑机接口。
API 出现在各种计算机系统中，例如：
软件库或框架
Java 平台标准版（Java Platform, Standard Edition）和 Java 开发工具包（Java Development Kit）是提供与操作系统、网络等交互 API 的示例；Flask API 是一个 Python Web 框架的示例。
计算机操作系统
便携式操作系统接口（POSIX）是由电气和电子工程师协会计算机学会（IEEE CS）制定的一套标准。POSIX 定义了 API，以确保不同操作系统（类 Unix 及其他）之间的兼容性。
基于网络的应用程序
此类 API 设计用于通过计算机网络通信的应用程序。典型的接口是 Web API，由 Web 服务器提供，Web 浏览器调用。浏览器主要使用 JavaScript Web API 与 Web 服务器交互。基于网络的 API 应用也可以无浏览器运行，如命令行工具、移动应用和桌面应用。
正如你所见，API 在各种计算机系统中广泛使用。API 提供了特定的功能和能力，使得你作为 API 用户无需从零实现这些功能。API 隐藏了系统的复杂性，你只需将 API 视为一个黑盒。根据 API 文档，提供输入并获得输出，同时伴随交互过程中的任何副作用。
基于网络的 API
本书聚焦于基于网络的 API。基于网络的 API 是一种交互点，允许软件通过网络（通常是互联网）进行通信。
注意
本书中介绍的大多数 API 属于 Web API 类别。Web API 使软件能够通过互联网通信，并利用诸如网页浏览器和 HTTP 协议等网络技术（有关 HTTP 的更多细节，请参见第4章）。然而，Web API 这一术语将 API 限定在基于 Web 的架构和技术范围内。因此，我们更倾向于使用更广义的术语——基于网络的 API。所以，当我们提到 API 时，除非另有说明，否则指的都是基于网络的 API。
接下来，我们将在基于网络的应用程序背景下继续解释 API 这个缩写。图 1-2 展示了客户端-服务器架构中典型 Web 应用程序的组成部分。
以下列表解释了 API 缩写中每个词的含义：
Application（应用）
虽然“应用”一词在图 1-2 中只出现在服务器端，但应用实际上存在于图示的两端——即客户端和服务器端。服务器应用可以被视为一个黑盒。在这个黑盒中，具体的实现细节被隐藏。我们知道输入进入黑盒，经过一系列变换（通常外部观察者无法知晓），最终产生预期的输出。在 Web API 的语境下，服务器端应用称为后端，客户端应用称为前端。后端应用提供数据，前端应用消费数据。
Programming（编程）
编程是向计算机提供指令以执行任务的过程。服务器应用所提供的功能可以被看作是由客户端应用“编程”实现的。虽然“编程”这一术语在图 1-2 中只出现在服务器端，但实际上客户端和服务器端的应用程序都包含编程。也就是说，开发者通过使用相关的工具和库，将功能实现（编程）到前端和后端应用中。
Interface（接口）
接口允许系统之间进行通信和数据交换。接口是服务器应用向客户端应用暴露其功能的交互点。
一种形象地理解基于网络 API 的方式是，将其想象成一座连接两座城市的多车道收费桥，卡车从桥上通过，如图 1-3 所示。
在这个比喻中，桥两端的城市分别代表客户端和服务器端应用。连接两座城市的桥象征着数据流通的网络。
卡车进入桥梁时经过的收费站代表 API 风格。携带货物（消息）的卡车进出桥梁，象征着请求或响应。货物上的地址象征着 API 端点。卡车和货物会在收费站接受验证，确保请求和响应格式正确且经过授权。通过收费站验证后，卡车驶入桥梁并遵守既定的交通规则（这些规则定义了网络协议，详情可参见第3章）。
你可以利用这个比喻来描述“同步和异步通信类型”中定义的通信方式。具体来说，考虑卡车如何运送货物。在同步消息传递中，卡车送达货物后会等待收货确认（即确认货物已被接收）；而在异步消息传递中，卡车一旦交付完货物就会离开，收货确认则由另一辆卡车随后送回。
API 通信的概念
在更详细地探讨基于网络的 API 之前，我们还需要解释与网络数据交换相关的几个概念：消息、传输模式以及同步与异步通信类型。
消息
消息是由发送方发送给一个或多个接收方的离散数据单元（一个自包含的记录）。它通常包含有效负载（payload）以及描述消息的元数据。
在开放系统互联（OSI）模型中，消息一词与应用层协议相关（参见“TCP/IP 与 OSI 模型”）。下面列举几个应用层消息的示例：
- HTTP
示例 1-1 展示了一个典型的 HTTP/1.1 POST 消息（有关 HTTP 的更多信息，请参见第4章）。该消息包含 POST 请求行，接着是三个头部和消息体（comment=Hello）。
示例 1-1. 由 POST 请求承载的 HTTP 消息
POST /submit HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
comment=Hello
- XMPP
示例 1-2 展示了一个可扩展消息与存在协议（XMPP）中以 XML 编码的消息（XMPP 流的一部分）。注意 XML 属性如何用来描述消息的元数据。
示例 1-2. XMPP 流中的 XMPP 消息
<?xml version='1.0'?>
<stream:stream ...>
<message from='sender@example.com' to='receiver@example.net' xml:lang='en'>
<body>Hello</body>
</message>
</stream:stream>
- MQTT
示例 1-3 展示了使用 MQTT 协议发送的二进制消息的表示；MQTT 中的消息称为数据包。MQTT 数据包包含固定头部、可选的可变头部和有效负载。该数据包描述的是 PUBLISH 控制包类型。可变头部包含主题名（sensor/temperature），有效负载包含数据（25.5°C）。
示例 1-3. MQTT PUBLISH 数据包概要
固定头部: PUBLISH ...
可变头部: sensor/temperature
有效负载: 25.5 C
传输模式
传输模式（也称为数据传输模式）一词来源于电信领域，用来描述通信双方之间数据的共享方式。图 1-4 展示了三种不同的传输模式，这些模式可用于通信中涉及的服务（或设备）之间传输数据。每个通信方可以处于以下三种状态之一：发送、接收，或同时发送和接收。
注意
传输模式并非 API 独有。任何需要交换信息的系统，无论是硬件设备还是软件组件，都必须实现适合的传输模式。
让我们来看看不同的传输模式：
单工（Simplex）
单向传输模式，数据只在一个方向流动，从发送方到接收方。例如，收音机或电视就是单工设备，因为你只能接收数据。
半双工/半双向（Half-duplex/Semi-duplex）
双向传输模式，但数据流不是同时发生的。数据可以双向流动，但每次只能一个方向传输，从发送方到接收方。对讲机就是采用半双工模式的设备。使用对讲机通信时，双方必须遵守通信协议（比如使用“over”和“out”这样的词汇）。
全双工/双工（Full-duplex/Duplex）
双向传输模式，数据可以同时双向流动。电话就是使用全双工模式的设备。在电话通话中，你可以一边说话一边被听见。
同步与异步通信类型
“同步”（synchronous）一词来源于希腊语 syn，意为“共同”，以及 chronos，意为“时间”。因此，同步通信需要协调的时间，而异步通信则不需要。例如，在电信领域，同步通信涉及共享时钟，确保接收方能够按照发送方定义的速率正确采样和解释信号。这表明同步和异步通信的概念并不限于请求-响应模型。
同步通信的例子包括电话和视频聊天，参与者期望同时互动。电子邮件和论坛帖子是异步通信的例子，消息在不同时间发送和接收，无需同步协调。在异步通信中，参与者在发送或接收消息后可以自由处理其他任务，从技术角度看，这意味着可以进行非阻塞处理。
图 1-5 展示了同步和异步通信的区别，图中两方遵循请求-响应模型。
在同步的请求-响应通信中，发送方发送消息给接收方后，会等待对应的响应。在等待响应期间，发送方处于阻塞状态，意味着发送方无法继续执行后续操作（或开始新任务），直到收到响应。同步通信成功的前提是发送方和接收方在消息交换过程中都必须处于活动且可用状态。
在异步的请求-响应通信中，发送方发送消息后不会被阻塞，而是可以开始执行其他任务，同时等待响应。在异步通信中，发送方和接收方不必在通信发生时同时在线。
网络协议的设计可能决定发送方采用同步还是异步通信方式。但如果协议允许灵活选择，发送方可以决定采用哪种通信风格。例如，HTTP 遵循请求-响应通信模型，每个请求都有对应的响应，因此你可能会默认使用 HTTP 的客户端是同步通信的。然而，使用 JavaScript 的 fetch() 方法发送 HTTP 请求时是异步通信；相比之下，使用 curl 发送相同 HTTP 请求则是同步通信。
API 的历史
API 这一概念比术语本身要早。虽然 API 一词起源于20世纪40年代，但直到60年代和70年代才开始广泛使用。
20世纪40年代，英国计算机科学家 Maurice Wilkes、David Wheeler 和 Stanley Gill 为一台名为电子延迟存储自动计算机（EDSAC）的早期计算机开发了模块化软件库。由此产生的文档，即首部计算机编程著作，提出了使用子程序作为计算机标准化接口的概念。用现代术语解释，这个概念可视为 API：
“为了使用库中的子程序，不必确切了解其构造方式或所采用的具体数值计算过程，只要有一份简明的说明文档，说明其功能和使用方法……为了使子程序适合被收录进库中，它必须以足够通用的形式设计，以便能在不同场景下使用，而用户无需对其内部进行修改。”
——《电子数字计算机程序准备》（1957）
图 1-6 显示了两张图片。上图展示了由存储机架和输入输出单元组成的 EDSAC。右侧矩形标记了插入磁带读取器的输入磁带，磁带读取器连接着打印结果的电传打字机。下图显示了一位操作员（程序员）使用键盘通过磁带读取器（图中央可见）将程序打孔到磁带中，以机械方式从库中复制所需子程序。左侧矩形标记了一个钢制柜子，里面存放着已打孔的子程序磁带库。
“应用程序接口”（application program interface，注意 program 一词无 -ing 后缀）这一术语首次由 Ira W. Cotton 和 Frank S. Greatorex 在他们1968年的论文《远程计算机图形的数据结构与技术》（Data Structures and Techniques for Remote Computer Graphics）中使用。作者用该术语描述应用程序与计算机系统之间的交互。他们解释说，该系统设计为硬件无关，使其能够适应不同硬件，而保持应用程序接口不变。
随着计算机网络在20世纪70至80年代的普及，程序员希望不仅调用本地计算机上的库，也能调用远程计算机上的库。API 的概念因远程过程调用（Remote Procedure Call，详见“远程过程调用”部分）进一步扩展。
进入90年代，计算机继续在不同环境、操作系统和编程语言间运行。对象管理组织（Object Management Group，OMG）定义了通用对象请求代理架构（Common Object Request Broker Architecture，CORBA）标准。CORBA 对编程语言无偏好，允许远程调用分布在不同系统中的对象并操作它们。CORBA 绑定支持跨语言的对象交互，对象用接口定义语言（IDL）语法描述。
1993年，微软的组件对象模型（Component Object Model，COM）解决了与 CORBA 类似的问题，但针对使用应用程序二进制接口（Application Binary Interface，ABI）的二进制程序。与硬件无关、定义源代码级程序访问的 API 不同，ABI 是硬件相关的，定义了机器码级别的函数和数据结构访问方式，使二进制程序能够通信。
1998年，简单对象访问协议（Simple Object Access Protocol，SOAP）诞生，作为一种在 Web 服务之间交换 XML 格式消息的协议。SOAP 使用应用层协议，主要是超文本传输协议（HTTP），偶尔也使用简单邮件传输协议（SMTP）。SOAP 因消息体积大而冗长、解析速度慢且未定义统一的交互模型（不能强制客户端与服务器的交互方式）而受到批评。
2000年，Roy Thomas Fielding 在其博士论文《架构风格与基于网络的软件架构设计》中提出了表现层状态转移（Representational State Transfer，REST）概念，描述了一种基于网络的 API 思想。
API 授权令（API Mandate）
2000年，Fielding 引入的 REST 架构风格推动了公共互联网基于网络 API 的采用。紧接着，另一个被称为 API 授权令的文档揭示了这一趋势也在企业内部流行。据说，大约在2002年，亚马逊 CEO Jeff Bezos 向员工发布了一份备忘录（即 API 授权令）。该授权令是以面向服务架构（Service-Oriented Architecture，SOA）的背景写成的。如果用现代语言重新表达其原则，内容大致如下：
- 服务数据和功能通过 API 公开。
- 服务仅通过 API 进行通信。
- 除基于网络的 API 外，不允许使用其他通信方式。
- API 应采用符合上下文的技术实现。
- API 设计应确保能够对外部客户开放。
21世纪初，尤其是2010年代，API 技术得到了迅猛发展，因此这段时期被称为“API 时代”。以下是该时期出现的一些 API 技术时间轴：REST（2000）、Webhook（2007）、WebSocket（2011）、GraphQL（2015）和 gRPC（2015）。
为什么要用 API？
你可能会好奇，API 为什么这么重要？我们将从个人、开发者和组织三个角度来回答这个问题。
人们普遍认为应该投入时间培养软技能——比如时间管理、沟通能力或团队合作等通用职场技能。软技能可能帮助你获得面试机会，但组织真正寻找的是能够帮助实现目标的候选人。因此，组织更看重具备特定技能组合（如 x、y、z 技能）的候选人，这些技能既可能是软技能，也可能是硬技能。作为候选人，如果你拥有组织所需的技能，你就更具优势。无论你是软件开发者，还是负责网络应用的架构师，投资于 API 技能的提升都非常值得，因为这类技能在不同岗位和行业间具有可迁移性。
注意
Gartner 2023 年发布的《API 趋势》报告显示，38% 参与调查的组织计划在明年新增 API 开发岗位。
API 促进基于模块化架构的开发，使组件（服务）尽可能独立地构建和管理。API 还通过确保各系统通过标准化接口通信，增强了互操作性。如有需要，还能支持向面向服务架构（SOA），例如微服务架构的转型。
组织的目标之一是创造利润。在日益网络化的世界里，理解“每个业务都是软件业务”这一观点，能够认识到组织的线上存在会影响利润。API 可以帮助组织实现增长，连接内部和外部服务，并推动软件构建，具体表现在：
- 创造新的收入来源
例如，Skyscanner 这样的网站作为 API 聚合平台，主要通过 API 查询航空和酒店报价，使数据可搜索，用户可选择心仪的航空或酒店，从而为航空公司或酒店带来新的收入，同时也为 API 提供商创造收入。据报道，Salesforce、eBay 和 Expedia 等公司的收入有超过一半来源于 API。 - 扩大市场覆盖范围
视频通信平台 Zoom 除了可通过网站访问，还支持智能手机、平板电脑、桌面和智能电视。向移动设备开放 API 的公司可能接触到全球大量用户。 - 获取最新技术
2021 年，GitHub 发布了基于生成式预训练变换模型（GPT）的工具 GitHub Copilot，该模型训练于数百万代码仓库。随着时间推移，GitHub Copilot 从代码补全工具演变为编码助手。OpenAI 通过公开模型 API，使 GitHub（及其他公司）能够访问模型的更新版本。
私有、公有和合作伙伴 API
API 可以按照访问类型进行分类：
- 私有 API
也称内部 API，在组织内部开发使用，主要用于组织内部各单元之间的数据交换。- 公有 API
由组织向公众开放。公有 API 所提供的服务或数据可能免费，也可能由组织进行商业变现。例如，Open-Meteo 的天气 API 对非商业用途免费，商业用途收费。- 合作伙伴 API
仅对开发该 API 的组织及其合作伙伴开放访问。
什么是 API 风格？
要理解 API 风格，我们可以将其类比于土木工程中的建筑风格。建筑风格是指一套影响建筑设计、功能和外观的特征、方法、材料、结构以及区域和文化因素。建筑风格通常与某个历史时期相关，并有独特名称来概括其特点，比如罗马风格、希腊风格、文艺复兴风格、巴洛克风格、维多利亚风格或民间风格。
同样的思路也适用于软件和 API。我们将 API 风格定义为一种范式，它通过一组模式、实践和协议来设计、实现和暴露 API。类似建筑风格，API 风格有其特定的目的和功能，并随着时间演变。
定义 API 风格有趣的一点在于，每种独特风格都是由若干特征（如协议、设计约束等）混合而成，其中某些特征会主导该风格。举个例子，就像一个乐队。一个典型乐队包含鼓、贝斯、吉他、键盘和主唱五种乐器。仅凭这五种乐器，乐队就能演奏摇滚、流行、雷鬼等多种风格。乐队还可以融合不同风格，创造流行摇滚、放克摇滚或爵士放克等混合体。但乐队通常以主导风格来定义自己，而非使用的乐器集合。API 风格亦是如此。尽管各种 API 风格可能使用相同的“乐器”（协议、通信类型、设计原则或约束），真正定义一个 API 风格的是其最具主导性的特征集。我们可以将 API 风格分类如下：
- REST/RESTful
RESTful API 遵循 Roy Fielding 博士论文中提出的六项约束。虽然很多 API 自称 RESTful，但实际常常忽略了超媒体链接的包含，而这正是 RESTful 设计的必要条件。REST 在第5章有详细介绍。 - 基于查询（Query-based）
该风格的主导特征是允许客户端查询 API 并返回特定格式的数据。代表技术是 GraphQL（第6章介绍）。GraphQL API 暴露一个端点，客户端发送查询，指定需要检索的字段。 - Web Feed
该风格的核心特征是能够持续以结构化格式推送更新内容。知名例子有 RSS（Really Simple Syndication，亦称 Rich Site Summary）和 Atom 标准，两者均基于 XML 组织数据，HTTP 用作应用协议。该风格详见第7章。 - 远程过程调用（RPC）
该风格以调用远程服务器上的函数（过程）为特征，表现得像本地执行一样。RPC 客户端向暴露该过程的服务器发送调用请求，计算结果返回给客户端。领先的技术框架是 gRPC（第8章介绍）。 - 回调（Callback）
该风格的主要机制是回调。涉及两方：创建和处理回调的目标系统（接收消息），以及调用回调的源系统（发送消息）。在回调 API 中，源系统发送的每条消息都应被确认。典型技术是 Webhook（第9章）。Webhook 类似事件驱动风格，触发回调的机制是事件，但不同于通过消息中间件路由，Webhook 直接通过 HTTP POST 请求通知目标系统，因此也称为 HTTP 回调。 - 双向（Bidirectional）
该风格允许客户端和服务器之间同时双向交换数据（参见图 1-4 中的全双工传输）。基于 WebSocket 协议或 gRPC 框架构建的 API 属于此类（WebSocket 在第10章介绍，gRPC 在第8章介绍）。 - 基于代理（Broker-based）
该风格特点是消息通过中间人——代理（Broker）传递。基于代理的 API 使用多种协议传递消息。常见代理系统包括 Apache ActiveMQ、Apache Kafka 和 RabbitMQ（第11章介绍）。
注意
还有许多其他分类网络 API 的方式。例如，《持续 API 管理》（O’Reilly，2021）一书提及五种 API 风格：隧道（tunnel）、资源（resource）、超媒体（hypermedia）、查询（query）和事件驱动（event-based）API。
表 1-1 各种 API 风格的主要特征
| 风格 | 技术 | 协议 | 通信类型 | 支持二进制数据 | 响应速度 | 开发难度 |
|---|---|---|---|---|---|---|
| RESTful | REST | HTTP | 同步 | 是 | 中等 | 中等 |
| Query | GraphQL | HTTP¹ | 同步 | 部分支持 | 中等 | 中等 |
| Web Feed | Atom | HTTP | 异步 | 部分支持 | 中等 | 低 |
| RPC | gRPC | HTTP/2 | 同步 | 是 | 高 | 高 |
| Callback | Webhook | HTTP | 异步 | 是 | 中等 | 低 |
| Bidirectional | WebSocket | WebSocket | 异步 | 是 | 高 | 中等 |
| Broker-based | RabbitMQ | AMQP | 异步 | 是 | 高 | 高 |
¹ 除 HTTP 外，GraphQL 也可使用 WebSocket 协议。
表中各因素定义如下：
- 技术
实现该 API 风格的典型技术示例。 - 协议
该技术主要使用的网络协议。 - 通信类型
该 API 风格最常用的通信类型，分为同步和异步（详见“同步与异步通信类型”）。 - 支持二进制数据
是否支持二进制数据传输。是表示默认支持，否表示不支持，部分表示支持但需应用层实现编码（如将图像编码为 Base64 字符串）。 - 响应速度
系统及时响应能力，依据《响应式宣言》（The Reactive Manifesto）分类为低、中、高。 - 开发难度
构建低复杂度最小可行产品（MVP）所需主观努力，分类为低、中、高。
API 作为产品
API 授权令（见“API 授权令”部分）改变了数字化组织对 API 的看法——从仅仅把 API 视为连接服务的“胶水”，转变为将其视为能够影响收入的财务构建模块。这一转变源于组织认识到 API 本身就是一种产品。
API 变现（API Monetization）
除了作为组织产品和服务的数字渠道外，API 还可以成为直接或间接的收入来源。通过 API 创收称为 API 变现。常见的变现模式有：
- 按使用付费（Pay-per-use）
用户根据调用次数、交换数据量或其他使用指标支付费用。这种模式计费精准，适合用户需求不确定的情况。但需要配备精准的调用跟踪工具，便于计费并让用户了解和预测使用成本。- 订阅制（Subscription）
用户支付固定订阅费用（月度或年度）。此模式收入可预测，通常与更多调用次数或高级功能组合提供。- 免费增值（Freemium）
免费提供 API 的基础功能，针对高级功能、更高使用量或优质支持收费。基于扩大用户基础并将免费用户转化为付费用户的假设。- 交易手续费（Transaction fee）
对通过 API 完成的每笔交易收取费用。常见于电商和金融服务 API。例如，针对每笔支付交易收取一定比例的手续费。- 收入分成（Revenue sharing）
API 收入在第三方开发者和 API 提供商之间分成。此模式常见于联盟营销或市场平台，例如第三方旅游网站整合你的酒店预订 API，用户通过网站预订酒店时，你可获得部分佣金。
理解 API 作为产品，首先需意识到大多数组织将 API 视为集成技术。这种思维导致 API 在范围、可扩展性和持久性方面价值有限，设计不足，文档欠缺，缺少设计标准、版本控制和安全措施，或将可扩展性作为事后考虑。
将 API 当作产品对待意味着给予它与其他资产同等的关注。此类 API 的成功不仅基于营销或设计，更取决于第三方开发者的体验。满足他们的需求，可以提升 API 的采纳率。近年来，Backstage、Clutch 和 Cortex 等开发者门户越来越受欢迎，这类产品有助于内部 API 的发现和管理。
拥有 API 即产品的思维，要求你关注 API 使用情况和技术指标。作为 API 产品负责人，你需要了解：谁是 API 的高频用户？请求来自哪些地理区域？API 抛出了哪些错误？错误率是多少？响应时间如何？因此，你需要具备监控 API 并生成使用报告的工具。
提示
如果你想从产品视角深入了解 API，推荐阅读 Bruno Pedro 的《Building an API Product》（Packt Publishing，2024）。
与任何数字产品一样，你需确保 API 安全。因此需要考虑认证和授权（见“加密、认证与授权”），制定策略和限流规则，并对异常流量发出警报。
注意
将 API 向公众开放意味着承担维护责任。公开 API 需要遵守发布和废弃流程，如沟通和废弃时间表。API 发布后，难以撤销之前的错误。一个实际的 API 废弃案例是 Facebook（现 Meta）规划并通知停止第三方开发者访问其 Groups API。
API 生命周期
软件开发生命周期（SDLC）是用于管理软件应用从规划到退役全过程的流程。需要明确的是，API 本质上是一种软件，因此应当被视为软件。API 生命周期这一术语在 API 语境下与 SDLC 同义。即使你没有严格遵循 API 生命周期，了解其各个环节也有助于指导你的工作方法。
API 生命周期描述了 API 如何被规划、设计、实现、测试、部署、维护和退役。图 1-7 展示了其各个阶段。
注意
通常，API 生命周期（或 SDLC）中的各阶段被理解为独立且顺序执行的，实际上这些阶段是相互关联并相互作用的。例如，实现阶段可能会发现设计阶段未考虑的因素，从而导致对原设计的修改。此外，我们未指定流程的起始阶段，因为这取决于你项目的具体时间线和上下文。
你可能会注意到，生命周期图中似乎缺少了两个阶段（虽然通常会被包含）：安全性和文档。一些描述 API 生命周期的图表将安全性单独列为一个阶段，这存在问题，因为这暗示了安全意识仅限于某一个环节。我们认为安全应贯穿于 API 生命周期的所有阶段。
有些项目会将文档的编写推迟到维护阶段，理由是软件尚未成型，无法完整编写文档，因此不如暂时不写。但这种做法存在缺陷，最重要的是可能永远找不到时间去写文档，因为软件永远不会真正“完成”，直到它被退役。更现实的做法是，在 API 生命周期的所有阶段都至少起草部分文档。
规划阶段
采用代码优先（code-first）方法的开发者往往忽略规划阶段，但规划对项目成功至关重要。规划阶段是做出关于 API 决策和考量的关键时期。
除了定义项目的范围、进度、目标、交付物和截止日期外，规划阶段为 API 打下基础。在此阶段，负责人、架构师和开发者会识别组织目标、了解目标用户群，并正式确定 API 的功能性需求和非功能性需求。功能性需求（Functional Requirements, FR）描述软件功能，非功能性需求（Nonfunctional Requirements, NFR）描述软件质量。例如，构建搜索引擎时，一个功能性需求可能是允许用户通过 API 发送搜索查询，非功能性需求可能是 API 必须在一秒内返回查询结果。
功能性需求与非功能性需求
在系统设计中，不同阶段会产生多种需求，如用户需求、业务需求、法规需求、系统需求、架构需求、功能性需求、非功能性需求和实施需求。
但从设计者视角来看，软件开发生命周期（SDLC）的前三个阶段主要关注功能性需求和非功能性需求。将需求分为 FR 和 NFR 有助于优先安排设计与开发工作，或沟通需求带来的风险。
- 功能性需求（FR）
系统应完成的具体功能、任务或行为。FR 可从用户角度描述（用户在系统上执行某操作），也可从系统角度描述（系统执行特定动作）。例如，“用户应能重置密码”或“服务应允许管理员禁用用户访问”。- 非功能性需求（NFR）
系统应遵守的能力和约束，描述系统质量。也称为架构重要需求、软件架构特征或质量属性。NFR 描述系统的“ilities”，如可部署性、可维护性、性能、安全性和可用性。例如，“系统应响应迅速”或“系统应有 99.9% 可用性”。功能性需求和非功能性需求有时界限模糊。例如，“服务提供及时天气警报”既是功能性需求，也可视为非功能性需求：
- 服务提供天气警报 —— 功能性需求（服务提供功能）
- 服务提供及时警报 —— 非功能性需求（服务及时响应）
面对 FR 和 NFR 的取舍时，可思考以下问题：
- 该需求是否提供具体功能？
- 该需求是否影响系统的“ilities”？
- 该需求是否强制系统或功能以某种方式运行？
- 该需求是否涉及系统的输入或输出？
由于系统会在实施阶段后继续运行，非功能性需求的影响不会立即显现，需要时间逐渐体现。
规划阶段需回答的问题：
- API 的范围是什么？
是私有的（组织内部构建），还是公开的（面向外部用户）？或者是合作伙伴 API，用于促进组织间协作？ - API 的用户设备有哪些？
是物联网设备（IoT）、网页浏览器、手机、AI 代理，还是其他类型？ - 有哪些需求？
设计者是否对 API 施加了编程语言或框架限制？是否要求所有 API 响应在某个时间限制内完成？API 是否依赖外部服务？ - API 应支持的规模是多少？
预计用户数量大致多少？ - 采用何种版本控制策略？
使用语义化版本（Semantic Versioning）还是基于发布日期的版本？ - API 是否存在约束？
是否有法规约束，如《通用数据保护条例》（GDPR）或《健康保险携带与责任法案》（HIPAA），可能影响 API 功能？ - 是否已有 API 用户的沟通渠道？
将在哪里以及如何向 API 用户提供文档？文档访问是公开还是受限？
这些只是实现 API 前需回答的一部分问题。此外，在规划阶段起草 API 时，应将安全性和合规性融入需求制定过程。
设计阶段
在设计阶段，设计人员（架构师和开发者）基于对 API 受众、需求和规划阶段提取的约束的理解，确定 API 设计方案。设计阶段不仅关注 API 应该提供什么功能，还关注如何提供这些功能。在此阶段，设计人员决定是否集成第三方解决方案，以及选择何种技术和工具。
API 优先方法（API-First Approach）
设计 API 的一种方法是 API 优先策略。该方法主张先创建 API 规范（基于组织和 API 用户的需求收集而成），随后才进行实现。这种方法适用于可以访问预期 API 用户并在实现前就 API 形式达成一致的情况。
设计人员可能选择 API 优先方法，从而创建 API 规范，通常使用被广泛支持的规范格式，如 OpenAPI 或 AsyncAPI。支持这些格式的软件工具还可以辅助 API 的实现、测试以及文档生成。
API 设计主题将在第2章详细讨论。
实现阶段
实现阶段是将设计转化为代码，锻造软件的过程，因此我们也称其为应用架构阶段。
规划阶段提取的需求和设计阶段创建的 API 规范被转化为代码。但请记住，实现阶段的反馈可能导致重新审视并调整之前阶段的决策，进而修改需求或 API 规范。
同时，需要注意的是，系统的实际行为由实现决定。尽管实现细节应隐藏在接口之后，但它们仍可能泄露并被观察到。
接口与实现
Gregor Kiczales 在《走向软件工程中新的抽象模型》（“Towards a New Model of Abstraction in Software Engineering”）中指出：
“我们操作的‘抽象’实际上并非抽象。它们背后是实际的代码，在真实的机器上运行，消耗真实的能量，占用真实的空间。试图完全忽略底层实现，就像试图完全忽视物理定律一样；虽然诱人，但不会走得太远。”
—— Gregor Kiczales，1992年这一观点被称为“有漏洞的抽象定律”（Law of Leaky Abstractions）：
“所有非平凡的抽象，在某种程度上都是有漏洞的。”
—— Joel Spolsky，2002年如今，这种实现细节通过 API 接口暴露的现象被称为海鲁姆定律（Hyrum’s Law）：
“只要 API 用户足够多，你在合同中承诺什么并不重要：系统所有可观察的行为都会被某些人所依赖。”
—— Hyrum Wright，2012年漏洞抽象使 API 用户依赖系统的内部行为，这称为隐式接口。这种依赖使得修改 API 变得困难。
此外，API 的安全性也受到实现阶段实际选择的影响。加密、认证、授权以及安全编程实践（包括输入输出校验等，详见“API 安全”部分）是构建安全 API 的关键要素。
测试阶段
在测试阶段，API 会针对功能、安全性和性能进行测试。开发人员和质量保证（QA）团队负责设计和执行测试。测试通常可以与实现阶段并行进行，测试结果可能影响设计、实现或部署等其他阶段。
测试是 API 开发的重要部分，具体感受可能因测试内容和方式而异：既可能令人望而生畏，也可能充满乐趣。为什么测试如此重要？测试有助于创建可维护的软件，验证系统功能，发现缺陷（但不能证明无缺陷），并增强重构时的信心。测试可以手动执行，也可以自动化执行，尤其是在持续集成/持续交付（CI/CD）流水线中（详见“部署”）。流水线中的测试可以帮助开发者持续发现软件问题，保障软件质量。
集成测试
集成测试检查组件之间的协作情况，包括软件与外部服务（如数据库、文件系统和第三方 API）的交互。与关注单个代码单元的单元测试不同，集成测试保证这些组件在整体系统中协同工作。
借助 Docker 等工具，集成测试变得更容易。Docker 可以启动所需服务（如数据库、缓存、消息队列）的隔离容器，从而对真实运行的服务进行测试，避免仅用模拟对象，提高测试的真实性。如果某些第三方服务无法本地运行，可以尝试搭建独立测试实例，并配置集成测试与之交互。虽然这种方式能让测试在受控环境中与真实服务交互，但可能不够稳定，导致测试出现不可预期且不可重现的错误。
如果允许使用生产数据进行测试，可以将服务响应导出到文件（如 response.json），集成测试从文件读取响应。这种“录制-回放”测试方法可模拟服务，保证测试可重复执行，避免与实时环境发生意外交互。
合同测试与模糊测试
另一种集成测试方法是合同测试。合同测试源自 Robert W. Floyd 20世纪60年代末提出的通过断言证明程序正确性的方法。此方法及后续的霍尔逻辑（1969）和设计合同（1986）旨在证明程序在合法输入下会产生预期结果：
“人们写代码、跑测试、修补漏洞、再找漏洞……直到找不到新错误，但始终担心新情况会导致新的失败。我们从未意识到可能存在构建严格有效性证明的方法。”
—— Donald E. Knuth，2003
如今，API 合同测试不再是为固定的 API 消费者和提供者（如客户端-服务器架构中的双方）提供严格有效性证明，而是检查不断演变的消费者和提供者是否仍然遵守合同（API 规范）。API 规范通常以静态形式存在，描述数据结构、内容、消费者请求和提供者响应。但 API 也可能包含超出静态规范的行为，例如只有特定输入组合有效，或实现了速率限制，这些不一定在规范中体现。
类似录制-回放方法，可以保存一组历史请求和响应，验证它们与当前消费者和提供者实现是否符合规范。合同测试类似回归测试，检测消费者和提供者是否持续遵守 API 合同。若合同测试自动化集成到开发流程，可及时发现合同违规。例如，它可检测提供者的改动是否与消费者支持的版本不兼容，或是否能移除仅被弃用消费者使用的字段。
合同由消费者或提供者编写，分别称为消费者驱动合同（Consumer-Driven Contract, CDC）和提供者驱动合同（Provider-Driven Contract, PDC）。CDC 中，消费者定义服务行为，提供者负责实现合同。该方式更依赖提供者，因其需跟进消费者规范。PDC 则相反，提供者定义合同，消费者遵守。
合同测试的限制在于通常难以捕获足够大规模的请求和响应集以覆盖 API 合同。采用防御式编程（详见“防御式编程”）时，输入和行为范围广泛，难以全面捕获，因错误处理和恢复优先。与此相对的是攻击式编程（fail-fast），程序遇到错误输入即停止。
因此，合同测试常与 API 模糊测试（Fuzzing）结合，后者通过随机输入覆盖更多 API 规范部分，期望 API 能优雅处理异常输入。
端到端测试
端到端测试模拟用户与系统的交互，验证系统整体功能。端到端测试通常从 API 用户角度执行，传统上多为手工完成。如今，Cypress、Playwright 和 Selenium 等工具可自动化这部分工作，但使用这些工具时需准备应对一定程度的测试不稳定性。
敏捷测试象限
测试领域复杂，作为开发者你会创建多种测试。为了获得全局视角，可以参考图 1-8 中的敏捷测试象限图，将不同测试工具和方法分类。横轴从团队支持到产品评审，纵轴涵盖面向用户和面向技术的影响。
让我们来细分每个象限的职责：
Q1 象限
该象限的测试以技术为中心，旨在支持开发团队。单元测试和组件测试通常由开发者编写并实现自动化。由于这些测试执行快速，能为开发者提供即时反馈，激发他们的兴趣。
Q2 象限
该象限的测试从软件用户的角度出发，同时支持开发团队。测试重点是系统功能，确保系统满足用户目标。当自动化测试不可行时，应考虑手动测试。
Q3 象限
该象限的测试以用户为中心，对产品进行评判。测试旨在发现开发过程中遗漏的问题。用户验收测试（UAT）通常在此进行，通常有助于提升用户体验。但缺点是 UAT 多为手工执行。
Q4 象限
该象限的测试以技术为中心，对产品进行评判。测试内容偏技术性，关注非功能性需求（NFR），如安全性和性能。通常需要专业工具来完成这类测试。
Q1 和 Q2 支持开发过程，确保产品符合功能性需求（FR）；而 Q3 和 Q4 则聚焦于评估产品，确保满足用户需求并符合非功能性需求（NFR）。测试象限图为软件质量和可维护性提供了测试路线图。
部署阶段
部署是将软件工件迁移到其运行环境的过程。该过程通常包括软件打包、配置和环境准备，且可以手动或自动执行。将 API 工件（包括独立程序、相关规范和文档）迁移到目标主机听起来似乎很简单，但有运维经验的人都会告诉你，实际要复杂得多。本节将抛出几个问题，帮助你在规划 API 部署时进行思考。
首先要回答的问题是：负责 API 部署的团队如何组织？开发团队和运维团队是分开的，还是采用将两者融合的 DevOps 方式？DevOps 鼓励创建持续集成（CI）、持续交付（CD）和持续部署的流水线，实现软件的持续构建、发布和部署。
图 1-9 展示了 API 部署的步骤及 CI/CD 流水线之间的关系。
各种流水线的职责：
持续集成（Continuous Integration, CI）
该流水线负责构建工件。CI 阶段通常包括以下步骤：
- 代码风格检查（Lint） ：检查源代码是否符合编码规范。
- 静态代码分析：防止代码中出现不良、复杂或不安全的编程模式（如硬编码秘密或代码注入）。
- 依赖分析：检查代码是否使用过时或未授权的库。
- 构建：生成软件工件。
- 测试：测试构建后工件的功能。
- 安全扫描：检测工件中的漏洞并执行自动化渗透测试。
CI 流水线的输出通常是一个工件，例如容器镜像、本地二进制文件或特定平台的软件包。该工件随后被推送到目标仓库，如 Docker Hub、GitHub Packages、JFrog Artifactory 或传统的 FTP 服务器。
持续交付（Continuous Delivery, CD）
该流水线在 CI 完成后触发。它会在人工批准后，将 CI 构建的工件部署到目标环境。部署策略因 API 复杂度、组织需求和基础设施能力而异。常见的部署策略有蓝绿部署和金丝雀发布。
持续部署（Continuous Deployment）
该流水线实现自动将工件部署到目标环境，无需人工干预。此阶段关联的自动测试包括端到端测试、冒烟测试（验证最重要功能）、负载测试和压力测试等。
除了技术方面，DevOps 运动还试图打破开发团队和运维团队之间的“墙”，促进双方紧密协作，并共同承担产品生命周期的责任和问责。DevOps 团队还通过采用“左移”策略，将安全关注提前至产品生命周期早期，而非等到最后（即“右移”）。这种方法称为 DevSecOps。
注意
网络上一句匿名语录指出：“左移增加摩擦，右移增加正确性。” 给开发者增加负担会降低新功能开发能力。面对频繁失败的安全检查，团队可能会选择禁用检查，使得左移策略失效。
DevOps 运动基于自动化，并通过将运维任务下放到基础平台（包括安全检查）来减轻开发者负担。但独立的 DevOps 或 DevSecOps 团队的存在表明，DevOps 运动推广的某些理念可能不可行，因为单个开发者难以承担多重不同职责。
当你拥有了构建好的 API 工件，接下来的问题是部署到哪里？这就是传统的“买还是造”的困境。根据需求，API 工件可以部署到专有云厂商平台、自建云原生环境或本地机器。如果选择自建，会面临搭建和维护像 Kubernetes 这样支持高可用和弹性扩展的容器平台的高额人工成本；如果选用更简单的工具如 Kamal，初期人工成本较低，但后续可能因手动容量管理而产生更高人力投入。
买还是造的抉择不仅影响部署目标，还涉及支持 API 运营的其他服务。你需要权衡是使用集成的、专有云厂商系统（具备代理、日志、密钥和安全管理），还是自行搭建基于开源或自研组件的更可控方案。
还有一个问题是，你计划将 API 部署到多少环境？生产环境是 API 的运行环境，但因合规原因可能禁止在生产环境中测试，且直接在生产环境部署未经测试的变更风险较大。部署到预发布（或测试）环境，可以在推送到生产前进行测试。此外，你可能还需要一个或多个专用开发（或功能）环境，用于进行潜在破坏性的实验，避免影响共享的预发布环境。维护多个环境时，还需决定版本控制分支策略如何映射到这些环境。
警告
请注意，增加环境会增加维护工作量，且各环境可能表现出与生产环境不同的行为，导致测试结果不一致。
“预发布不是生产环境，也永远不会是生产环境。”
—— Charity Majors，2019年
综上所述，部署 API 需考虑多方面因素，包括托管基础设施、环境、源码分支、打包、测试、安全、可扩展性、日志记录和监控。部署策略取决于 API 的规模、复杂度和预期使用情况。
维护阶段
维护是 API 生命周期中持续进行的阶段，且通常伴随着较高的成本。在此阶段，软件会进行补丁修复、更新、文档完善和改进，并监控其性能、安全威胁及用户活动。维护的目标是在 API 运行期间，保持其相关性和及时更新。
图 1-10 展示了传统的 ISO/IEC/IEEE 14764 标准对因修改请求产生的维护类型的分类。修改请求可能源于软件缺陷修正，也可能源于功能增强。缺陷修正是针对软件缺陷的修复，而增强则是对现有功能的改进或新增功能的添加。
让我们来探讨因修改请求而产生的五种维护类型：
纠正性维护（Corrective）
针对软件故障进行修复，通常是由漏洞或错误引起的，需要及时修补。纠正性维护费用较高，可能耗时较长。其中一种形式是紧急维护，需要进行非计划内的修改以保持系统运行。
预防性维护（Preventive）
着眼于预测和防止软件故障。相关技术包括软件重启（software rejuvenation），旨在消除累积的错误状态并释放系统资源。
适应性维护（Adaptive）
针对软件运行环境的变化进行修正或增强。此类维护由环境的动态变化驱动。
增量性维护（Additive）
因新增功能或增强现有功能的需求而驱动，通常是最常见的维护类型。
完善性维护（Perfective）
对软件进行改进，提升其性能、可维护性和用户体验。例如，通过性能调优解决瓶颈，重构代码以改善可维护性。
可观测性与分析 是维护阶段的重要组成部分。可观测性指的是监控 API 产生的请求和响应的效果，例如成功与失败的响应、流量大小、流量发送者、流量来源及 API 最近的使用时间。收集到的遥测数据会通过指标仪表盘进行可视化。在维护阶段，维护人员还会设置告警工具，以便及时响应紧急情况。
到目前为止，我们已经涵盖了导致 API 创建的各项活动：规划、设计、测试、实施、部署和维护。下一节将讨论聚焦于 API 弃用和退役的策略。
退役（Retirement）
API 不会永远存在，退役是 API 生命周期的最后阶段。导致组织退役 API 的典型原因包括：API 无法满足组织目标、API 具有安全威胁、新功能无法添加到现有 API、API 成本超过收入，或者组织的盈利策略从免费 API 转为收费 API。
没有退役计划的组织更容易出现安全隐患，比如“僵尸 API”（Zombie APIs），即被废弃且不再维护，但仍然存在于组织中的 API。僵尸 API 处于休眠状态，意味着它们被遗忘但仍然活跃，且仍可访问和交互。另一方面，如果 API 退役处理不当，可能会损害 API 团队和组织的声誉。
在退役阶段，可能会采用迁移计划支持多个 API 版本（新旧版本）并行运行。此外，该阶段应包含生命周期结束计划，说明如何在不影响运营的情况下弃用 API，并如何向 API 用户传达退役信息。
弃用（Deprecation）表示 API 仍然可用，但计划在以后某个时间移除或替换。弃用的决定取决于 API 的发布节奏。例如，如果管理 API 的政策是最多支持两个 API 版本，则在第三次发布时会移除第一个版本。举例来说，假设已经发布了两个版本 v1 和 v2，现在准备发布第三个版本 v3，那么发布 v3 时，会删除 v1，仅保留 v2 和 v3。
弃用和退役都有对应的日期。弃用日期表示从该时间起，API 将有限支持更新和修复错误。退役日期则表示从该时间起，API 将不再可访问。
如果你选择弃用 API，需通知 API 用户你的意图。例如，Kubernetes 在通过 CLI 创建弃用工件时，会打印警告信息，如图 1-11 所示。
另一种告知用户 API 弃用的方法是在 API 文档网站上显示弃用横幅。图 1-12 展示了 Google PaLM API 的弃用警告。
另一种选择是在 API 响应中添加关于 API 弃用的头信息。这种做法见示例 1-4。
示例 1-4. HTTP 弃用（Deprecation）和终止（Sunset）头信息
Sunset: Wed, 11 Nov 2026 11:11:11 GMT
Deprecation: @1688169599
Link: <https://developer.example.com/deprecation>; rel="deprecation"
Deprecation 头中的时间戳可以指向过去或将来的某个时间。过去的日期意味着 API 已经被弃用。而 Sunset 头中的日期总是指向未来，表示 API 何时退役。公共 API 的退役通常会持续数月之久。
Link 头可能提供关于 API 弃用的更多信息，包括文档链接。退役日期并不是唯一重要的信息，你还可以在弃用信息中加入联系方式、迁移指南，以及（如果有的话）下一版本发布的时间表。关于 API 弃用和退役的信息可能需要保存，以便满足合规审计或历史记录的需求。
API 治理、管理与平台
如果你是一个小公司，由单一团队负责管理 API，那么该团队将在 API 生命周期的每个阶段做出所有决策。但如果你是一个拥有多个团队构建 API 的组织，就需要制定相应的管理和治理计划。没有管理的 API 可能成为潜在的安全风险，导致未授权访问、数据泄露或 API 滥用。API 管理帮助你制定计划来应对这些风险。
治理是指组织为实现管理与控制而制定的成文与不成文的规则和流程。治理利用组织的权力结构来执行这些规则。
治理 API 意味着创建实践、标准和政策；将其传达给 API 团队；并在 API 中实施。为了确保政策得到遵守，治理还需要对 API 和团队的合规情况进行监控。
缺乏治理不仅会导致 API 不一致，还会产生影子 API（Shadow APIs），即活跃使用但无管理、无文档且未经组织正式监督部署的 API。相反，治理有助于保证 API 的安全、稳定、可复用，并符合监管政策。
API 管理的目标是标准化 API 生命周期各阶段的开发流程。例如，在规划和设计阶段，遵循设计标准和最佳实践；在实现和部署阶段，使用工具构建、测试和部署 API；在维护阶段，监控 API 并收集用户反馈。
API 平台是一种帮助编目、治理和管理 API 并与 API 用户互动的软件。它提供一套工具，支持 API 团队开发、发布、管理和使用 API。API 平台通常集成外部工具，如 CI/CD 流水线、云基础设施、监控工具，以及安全和合规工具。常见的 API 平台包括 Amazon API Gateway、Azure API Management、Google Cloud Apigee、Kong 和 MuleSoft Anypoint Platform。
提示
API Landscape 是一个展示各种帮助设计、开发和管理 API 工具的网站。不要被它的界面吓倒，很多工具会多次列出。
API 的未来
在了解了 API 的基础知识和历史之后，让我们来讨论它们的未来。
根据 Statista 数据，2024 年全球联网的物联网设备数量预计达到 180 亿台，其中包括 72 亿智能手机订阅，覆盖了大约全球 67.1% 的人口。物联网设备数量预计在未来几年持续增长。这些设备的许多功能都需要基于网络的 API 支持。
内容分发网络（CDN）提供商 Cloudflare 在其 2024 年《API 安全报告》中指出，60% 的动态（不可缓存）流量是基于 API 的。API 也是 Cloudflare 增长最快的流量类别之一。
另一个推动 API 需求增长的因素是人工智能（AI）和大型语言模型（LLM）的发展。训练 LLM 需要大量消费来自 API 的数据，包括文本、图像、音频和视频。随着企业开发基于 LLM 的服务，现有及新兴的 API 形式将助力它们的发展，成为数据进出服务的通道。
AI 还可以辅助 API 生命周期各阶段的相关任务，如设计、文档编写、实现和安全。因此，AI 将推动可用 API 数量的增加。即便在今天，只需提供几个请求/响应示例，AI 也能尝试粗略编写一个 API。
随着 AI 和物联网设备的增长，API 的安全性将变得更加重要。Gartner 在 2021 年预测，API 攻击将成为企业 Web 应用中最常见的攻击向量。Kong 2023 年《API 影响报告》预测，全球 API 攻击数量将在 2027 年翻倍以上。
新协议将促进新型 API 风格的形成和安全保障。HTTP 协议在持续演进，第三版（HTTP/3）已于 2022 年 6 月发布。WebTransport 协议旨在解决 WebSocket 协议的不足。模型上下文协议（Model Context Protocol，MCP）旨在帮助 LLM 和具代理能力的 AI 进行资源发现和使用。
如果这些预测可信，那么 API 的增长无疑将持续，不会放缓甚至倒退。
总结
本章介绍了 API 的概念，重点是基于网络的 API，这是本书的主要话题。你学习了理解网络 API 所需的基本词汇，如消息、同步与异步通信、网络协议。你了解了 API 的历史并考虑了未来的预测，表明 API 使用将持续增长。
本章还概述了本书涵盖的各种 API 类型，按其定义特征或风格进行组织。章节的大部分内容聚焦于 API 生命周期，即创建和管理 API 的过程。
下一章将介绍常见的 API 设计模式。
