API

概述

参考：

Application Programming Interface(应用程序接口，简称 API)。它定义了可以进行的调用或请求的类型，如何进行调用，应使用的数据格式，遵循的约定等。它还可以提供扩展机制，以便用户可以通过各种方式扩展现有功能。在不同程度上。API 可以是完全自定义的，特定于组件的，也可以基于行业标准设计以确保互操作性。通过信息隐藏，API 支持模块化编程，从而使用户可以独立于实现使用接口。

目的

在构建应用程序时，API（应用程序编程接口）通过抽象化底层实现并仅公开开发人员需要的对象或动作来简化编程。电子邮件客户端的图形界面可能会为用户提供执行获取和突出显示新电子邮件的所有步骤的按钮，而用于文件输入/输出的 API 可能会为开发人员提供一种将文件从一个位置复制到另一个位置的功能，而无需要求开发人员了解幕后发生的文件系统操作。

术语的历史

1978 年的一张图建议将 API 的概念扩展为一个通用的编程接口，而不仅仅是应用程序。

“API” 一词的含义已经扩展了其历史。首先，它仅描述了面向面向最终用户的程序（称为应用程序）的接口。此起源仍反映在名称“应用程序编程接口”中。如今，术语 API 的范围更广，不仅包括实用程序软件，甚至包括硬件接口。

API 的概念比该术语要古老得多。英国计算机科学家 Wilkes 和 Wheeler 在 1940 年代为 EDSAC 计算机开发了模块化软件库。约书亚·布洛赫（Joshua Bloch）声称威尔克斯和惠勒（Wilker and Wheeler）“潜在地发明”了该 API，因为它更多地是被发现而不是被发明的概念。

尽管创造 API 一词的人是在 Univac 1108 上实现软件，但他们的 API 的目标是使独立于硬件的程序成为可能。

术语“应用程序接口”（没有-ing后缀）首先被记录在称为纸张数据结构和技术对于远程计算机图形在呈现 AFIPS 在 1968 年会议[6] [4]所述的本文使用的作者该术语描述应用程序（在这种情况下为图形程序）与计算机系统其余部分的交互。一致的应用程序接口（包括 Fortran 子例程调用）旨在使程序员摆脱处理图形显示设备的特性，并在更换计算机或显示器时提供硬件独立性。

术语被引入到的场数据库由 CJ 日期中称为 1974 纸的关系和网络途径：应用程序编程接口的比较。 API 成为用于数据库管理系统的 ANSI/SPARC 框架的一部分。该框架将应用程序编程接口与其他接口（例如查询接口）分开对待。1970 年代的数据库专业人员发现，这些不同的接口可以组合在一起。一个足够丰富的应用程序接口也可以支持其他接口。

这种观察导致 API 支持所有类型的编程，而不仅是应用程序编程。到 1990 年，API 被技术专家 Carl Malamud 定义为“程序员可以用来执行某些任务的一组服务” 。

随着 Web API 的出现，API 的概念再次得到扩展。罗伊·菲尔丁（Roy Fielding）的论文《建筑风格》和2000 年在加州大学欧文分校（UC Irvine）的基于网络的软件体系结构设计概述了 REST，并描述了“菲林丁”与传统的“图书馆应用程序接口”的“基于网络的应用程序编程接口”的概念。基于”的 API。XML 和 JSON Web API 于 2000 年开始得到广泛的商业采用，并一直持续到 2020 年。

现在，Web API 是术语 API 的最常见含义。以这种方式使用时，术语“ API”与术语“通信协议”和“远程过程调用”在含义上有一些重叠。

用法

库和框架

API 通常与软件库有关。当库是这套规则的“实际实现”时，API 描述并规定了“预期行为”（一种规范）。

单个 API 可以采用共享同一编程接口的不同库的形式进行多种实现（或者没有一种实现是抽象的）。

将 API 与实现分开，可以允许以一种语言编写的程序使用以另一种语言编写的库。例如，由于 Scala 和 Java 可以编译为兼容的字节码，因此 Scala 开发人员可以利用任何 Java API。

API 的使用取决于所涉及的编程语言的类型。诸如 Lua 之类的过程语言的 API 可以主要由执行代码，操纵数据或处理错误的基本例程组成，而诸如 Java 之类的面向对象语言的 API 则可以提供类及其类方法的规范。

语言绑定也是 API。通过将一种语言的特性和功能映射到以另一种语言实现的接口，语言绑定允许在以另一种语言进行开发时使用以一种语言编写的库或服务。[15]诸如 SWIG 和 F2PY（一种从 Fortran 到 Python 的接口生成器）之类的工具有助于创建此类接口。

API 也可以与软件框架相关：框架可以基于实现了多个 API 的多个库，但是与 API 的正常使用不同，对框架内建行为的访问是通过使用新类扩展其内容来实现的插入框架本身。

而且，整个控制程序流程可以通过控制反转或类似的机制而不受调用者的控制，而不受框架的控制。

操作系统

API 可以指定应用程序和操作系统之间的接口。例如，POSIX 指定一组通用 API，这些 API 旨在使为 POSIX 兼容操作系统编写的应用程序能够为另一个 POSIX 兼容操作系统编译。

Linux 和 Berkeley 软件发行版是实现 POSIX API 的操作系统的示例。

Microsoft 已显示出对向后兼容 API 的坚定承诺，尤其是在其 Windows API（Win32）库中，因此较旧的应用程序可以使用称为“兼容模式”的可执行程序特定设置在新版 Windows 上运行。

API 与应用程序二进制接口（ABI）的不同之处在于，API 是基于源代码的，而 ABI 是基于二进制的。例如，POSIX 提供 API，而 Linux Standard Base 提供 ABI。

远程 API

远程 API 允许开发人员通过协议（特定于通信的标准）来操纵远程资源，该协议允许不同的技术一起工作，而不论语言或平台如何。例如，Java 数据库连接 API 允许开发人员使用相同的功能集查询许多不同类型的数据库，而 Java 远程方法调用 API 使用 Java 远程方法协议来允许调用可远程操作但在本地运行的功能开发人员。

因此，远程 API 对于维护面向对象程序设计中的对象抽象很有用。在代理对象上本地执行的方法调用，使用远程协议在远程对象上调用相应的方法，并获取要在本地用作返回值的结果。

代理对象的修改也将导致远程对象的相应修改。

Web API

Notes: 这里说的 Web API 是一种暴露 API 的方式，与 WebAPIs 不同，WebAPIs 是特指 Web 相关的所有 API，是具体的接口。

WebAPI 是企业和使用其资产的应用程序之间进行交互的已定义接口，这也是服务水平协议（SLA），用于指定功能提供者并为其 API 用户公开服务路径或 URL。API 方法是一种体系结构方法，它围绕为服务于不同类型消费者的不同应用程序提供一组服务的程序接口而发展。

当在 Web 开发的上下文中使用 API 时，通常将其定义为一组规范，例如超文本传输协议（HTTP）请求消息以及响应消息的结构定义，通常以可扩展标记语言（XML））或 JavaScript 对象符号（JSON）格式。例如运输公司的 API，可以将其添加到以电子商务为中心的网站上，以方便订购运输服务，并自动包括当前的运输价格，而站点开发人员不必在网络数据库中输入运输者的价格表。尽管 “Web API” 在历史上实际上是 Web service 的代名词，但最近的趋势（所谓的 Web 2.0）已从基于简单对象访问协议（SOAP）的 Web service 和面向服务的体系结构（SOA）转向更直接的表示状态转移（REST）样式的 Web 资源和面向资源的体系结构（ROA）。

这种趋势的一部分与语义 Web 向资源描述框架（RDF）的发展有关，RDF 是一种促进基于 Web 的本体工程技术的概念。Web API 允许将多个 API 组合到称为 mashup 的新应用程序中。在社交媒体领域，Web API 使 Web 社区可以促进在社区和应用程序之间共享内容和数据。这样，可以将在一个地方动态创建的内容发布并更新到 Web 上的多个位置。例如，Twitter 的 REST API 允许开发人员访问 Twitter 的核心数据，而 Search API 为开发人员提供了与 Twitter 搜索和趋势数据进行交互的方法。

设计

API 的设计对其使用有重大影响。信息隐藏的原理将编程接口的作用描述为通过隐藏模块的实现细节来实现模块化编程，从而使模块用户无需了解模块内部的复杂性。因此，API 的设计试图仅提供用户期望的工具。编程接口的设计是软件体系结构的重要组成部分，是复杂软件的组织。

发布政策

API 是技术公司更常见的集成方式之一。提供和使用 API 的组件被视为业务生态系统的成员。

发布 API 的主要策略是：

  • Private(私有)：该 API 仅供内部公司使用。
  • Partner(合作伙伴)：只有特定的业务合作伙伴可以使用 API。例如，Uber 和 Lyft 等租用公司的车辆允许经过批准的第三方开发人员直接在其应用程序内订购游乐设施。这使公司可以通过选择哪些应用程序可以访问 API 来进行质量控制，并为其提供额外的收入来源。
  • Public(公开)：该 API 供公众使用。例如，Microsoft 公开了 Windows API，Apple 发行了其 API Cocoa，因此可以为其平台编写软件。通常，并非所有人都能访问所有公共 API。例如，Cloudflare 或 Voxility 等 Internet 服务提供商使用 RESTful API，以允许客户和转售商访问其基础结构信息，DDoS 统计信息，网络性能或仪表板控件。可以通过“ API 令牌”或客户身份验证来授予对此类 API 的访问权限。

公共 API 的含义

API 公开时的重要因素是其“接口稳定性”。对 API 的更改（例如，向函数调用添加新参数）可能会破坏与依赖该 API 的客户端的兼容性。

当公开展示的 API 的某些部分可能发生更改并因此不稳定时，应将特定 API 的这些部分明确记录为“不稳定”。例如，在 Google Guava 库中，被视为不稳定的部分或可能即将更改的部分都标有 Java 注释 @Beta。

公共 API 有时可以声明其自身的某些部分_已弃用_或废除。这通常意味着应将 API 的一部分视为要删除或以向后不兼容的方式进行修改的候选对象。因此，这些更改使开发人员可以脱离 API 的某些部分，这些部分将来将被删除或不再受支持。

客户端代码可能包含 API 设计人员不打算使用的创新用法或机会用法。换句话说，对于具有大量用户基础的库，当元素成为公共 API 的一部分时，可以多种方式使用它。2020 年 2 月 19 日，Akamai 发布了他们的年度“互联网状况”报告，展示了针对全球金融服务中针对公共 API 平台的网络犯罪分子的增长趋势。从 2017 年 12 月到 2019 年 11 月，Akamai 见证了 854.2 亿次凭证违规攻击。大约 20％（即 165.5 亿）与定义为 API 端点的主机名相对。其中，4.735 亿针对金融服务部门组织。

文档

API 文档描述了 API 提供的服务以及如何使用这些服务，旨在涵盖客户出于实际目的需要了解的所有内容。

文档对于使用 API 开发和维护应用程序至关重要。API 文档通常在文档文件中找到，但也可以在社交媒体（例如博客，论坛和问答网站）中找到。

传统的文档文件通常通过具有一致外观和结构的文档系统（例如 Javadoc 或 Pydoc）来呈现。但是，文档中包含的内容类型因 API 而异。

为了清楚起见，API 文档可能包括对 API 中的类和方法的描述以及“典型的使用场景，代码段，设计原理，性能讨论和合同”，但是 API 服务本身的实现细节通常是省略。

该文档还涵盖了如何使用 API 的限制和限制。例如，对于一个 API 函数文档可以注意到，它的参数不能为 null，该函数本身没有线程安全的，因为 API 文档往往是全面的，它是作家保持更新文档和挑战用户仔细阅读它，可能会产生错误。

API 文档可以使用 Java 注释之类的元数据信息来丰富。编译器，工具和_运行时_环境可以使用此元数据来实现自定义行为或自定义处理。

可以以数据驱动的方式生成 API 文档。通过观察使用给定 API 的许多程序，可以推断出典型用法以及所需的合同和指令。然后，可以使用模板从挖掘的数据生成自然语言。


最后修改 August 22, 2025: api. clickhouse. (dc661496)