API接口

定义

API接口是一组标准化的请求规则，其作用是让两个或多个计算机程序彼此通信^[1]。它属于软件接口的一种，把某项能力提供给软件的其他部分使用；与连接人和计算机的用户界面不同，API 连接的是计算机或软件模块，它的使用者是把接口集成进程序里的开发者，而非终端用户^[1]。

API 规定的内容包括可以被调用哪些功能、调用时需要提交什么数据、数据以何种格式传递，以及返回结果的形式^[2]。常见定义把 API 描述为预先定义的函数，或者软件系统不同组成部分之间衔接的约定，使调用方能使用一组例程而不必访问源码，也不必了解其内部工作机制^[3]。

接口与实现是分离的：API 只规定预期的行为，具体的程序库或系统才是这一规定的实现，因此同一个 API 可以存在多个实现。POSIX 标准就是典型例子，它为符合该标准的操作系统规定了一套通用接口，使为其中一个系统编写的程序能够在另一个系统上编译，Linux与 BSD 即属此类^[1]。

原理

API 的理论基础是信息隐藏原则：模块只对外公开使用者需要的那部分接口，把实现细节留在内部，使用者无须掌握内部复杂性即可调用，从而实现模块化编程^[1]。这一原则带来解耦和复用的效果，同一段能力可以被多个程序共享，而内部实现更新时调用方的代码通常不必改动^[2]。

在网络环境下，调用过程表现为请求与响应：一方按约定格式发出请求，另一方的系统查询自身资源后，将结果通过接口返回。若以单次交互描述，可写作 $R = f(Q)$，其中 $Q$ 为请求参数，$R$ 为响应内容^[4]。Web API 通过超文本传输协议访问，请求与响应通常采用 JSON 或 XML 等机器可读格式，并借助 HTTP 状态码表示结果，例如请求成功或资源不存在^[5]。

REST 是设计 Web API 的主要架构风格之一，由罗伊·菲尔丁在 2000 年的博士论文中提出，包含客户端—服务器分离、无状态、可缓存、分层系统、统一接口等约束，其中代码按需下载为可选项^[4]。REST 接口以统一资源标识符定位资源，用不同的端点对资源执行创建、读取、更新和删除操作^[5]。菲尔丁本人强调，超媒体驱动是 REST 的限定性特征，缺少该约束的 JSON 接口严格来说并不符合 REST。

除了资源风格，接口还可以按调用方式区分。常见的 HTTP 方法包括用于查询的 GET 与用于提交的 POST，另有 PUT、DELETE 等用于修改和删除；从响应机制看，需要等待结果的为同步接口，发出请求后不必等待的为异步接口^[6]。在跨系统调用中，还常采用签名、令牌和接口版本来校验身份、防止参数被篡改^[7]。

发展历程

API 的思想早于这一术语。1940 年代末，剑桥大学的莫里斯·威尔克斯和戴维·惠勒等人为 EDSAC 计算机建立了可复用的子程序库，并编写说明各子程序用法的目录，这类说明相当于今天的接口文档；两人与斯坦利·吉尔于 1951 年出版的《为电子数字计算机编写程序》介绍了该子程序库的用法^[1]。

术语本身已知较早见于 1968 年 AFIPS 秋季联合计算机会议上的一篇远程计算机图形论文，其中使用「application program interface」描述图形程序与计算机系统其余部分之间的交互^[1]。1974 年，克里斯托弗·戴特与埃德加·科德在比较关系模型与网状模型的论文中把这一术语引入数据库领域；到 1990 年，API 已被宽泛地理解为程序员完成特定任务可调用的一组服务^[1]。

随计算机网络普及，接口从本地程序库走向远程调用。1984 年，施乐帕洛阿尔托研究中心的安德鲁·比雷尔与布鲁斯·纳尔逊发表远程过程调用的实现方案，使跨网络调用保持与本地过程调用相同的语义^[1]。2000 年，罗伊·菲尔丁在博士论文中提出 REST 架构风格，并区分「基于网络的 API」与传统的「基于库的 API」^[1]。HTTP/1.1 的第一个草稿发布于 1996 年 1 月，经过三年多修订于 1999 年 6 月成为正式规范，菲尔丁是该协议专家组的重要成员。

2000 年代起，XML 与 JSON 形式的 Web API 被广泛商业采用。2004 年 Flickr 推出 RESTful 接口，2006 年 Facebook 与 Twitter 相继开放基于 REST 的接口，同年谷歌推出地图接口，使整合既有内容的混搭应用开始出现^[8]。2005 年后随着 Ajax 与 Ruby on Rails 等技术的兴起，REST 风格受到更多关注，2007 年 1 月发布的 Ruby on Rails 1.2 版把支持 REST 开发列为优先方向。2014 年，詹姆斯·刘易斯与马丁·福勒给出被广泛引用的微服务定义，即把单个应用拆成一组各自运行于独立进程的小型服务，服务之间通过轻量级机制通信，通常是基于 HTTP 的资源接口^[1]。

应用

在操作系统与程序库层面，API 为应用程序提供图形与声音功能、网络通信能力、安全与数据转换，以及内存和硬件设备等系统资源的访问手段^[1]。微软的 Windows API 是 Windows 平台的主要系统接口，DirectX、SDL 与 Java API 等则属于常见的程序库与框架接口^[1]。图形处理领域的 OpenGL、通用计算的 OpenCL 与共享内存并行的 OpenMP 也都以标准接口的形式提供^[9]。

在互联网服务层面，开放 API 使外部开发者可以在不修改对方源码的前提下，增加系统功能或使用其资源^[3]。微信开放平台即通过接口向开发者提供语义理解等服务，调用时需先取得应用标识与密钥，再换取有时效的访问令牌，令牌有效期以秒计^[10]。中国银联的开放平台同样以统一规范向外提供产品接口，部分产品以令牌为凭证调用，约 2 小时内有效^[11]。

金融领域是开放 API 应用较集中的方向。香港金融管理局于 2017 年 9 月公布推动智慧银行的举措，制定开放 API 框架为其中之一；经公开咨询后，于 2018 年 7 月 18 日发布香港银行业开放 API 框架，按风险为本原则分 4 个阶段落实，从产品与服务信息逐步扩展至账户信息与交易^[12]。该框架建议采用国际惯用的技术与保安标准，并说明银行与第三方服务提供者的合作方式^[12]。在技术实现上，相关规范引用 OpenID Connect、OAuth 2.0 与金融级 API 只读安全配置等框架，并要求采用 HTTPS 传输与数字证书^[13]。

局限

接口本身只规定调用方式，能否稳定可用取决于提供方。服务中断、性能下降和破坏性变更都会影响依赖它的应用；破坏性变更包括删除允许的参数或响应字段、新增无默认值的必填参数、改动现有权限定义等，调用方若未及时调整，集成就会失效^[14]。接口因此通常需要版本化与弃用策略，并约定调用频次限制^[14]。

对外开放接口会扩大受攻击面。以银行业开放 API 为例，新增的外部接口使客户数据可被多方接触，带来未授权入侵、数据完整性受损的可能；生态各方技术依赖加深后，一方系统的故障也可能波及合作方，此外还存在数据隐私、责任划分与交易监测等方面的风险^[15]。相关框架要求客户作出明确同意、采用双因素认证，并保证客户可以查询、管理或撤回授权^[15]。

接口文档的完备与更新也是难点。文档往往内容繁多，编写者难以持续同步，使用者也可能未仔细阅读，由此产生缺陷^[9]。在制度层面，接口能否受著作权保护曾在美国引发长期诉讼：2010 年甲骨文起诉谷歌在 Android 中实现 Java 接口，2014 年初审裁决被上诉法院推翻，2016 年陪审团认定属合理使用，其后上诉法院又作出相反认定，谷歌于 2019 年上诉至美国最高法院^[9]。

参见

• REST —— API 设计中最常用的网络架构风格，规定了无状态与统一接口等约束。

• HTTP —— Web API 主要依托的传输协议，其方法动词与状态码构成接口语义的一部分。

• 远程过程调用 —— 让跨网络调用具有与本地调用相同语义的接口形式。

• 微服务 —— 把应用拆为多个独立服务、彼此通过轻量级接口通信的架构方式。

• 软件开发工具包 —— 封装并简化 API 调用的工具集合，通常在接口之上提供语言级封装。

• 应用二进制接口 —— 在二进制层面规定程序交互方式的接口，与源码层面的 API 相对。