以下是 API 的工作原理：
客户端应用启动 API 调用以检索信息，这也称为请求。 通过 API 的统一资源标识符 (URI) 处理由应用向 Web 服务器发出的请求。请求中包含请求谓词、标头，有时还包括请求主体。
收到有效请求后，API 会调用外部程序或 Web 服务器。
服务器向 API 发送包含所请求信息的响应。
API 将数据传输到最初发出请求的应用。
虽然数据传输因所使用的 Web 服务而异，但这种请求和响应的过程都通过 API 进行。 用户界面专为人类使用而设计， API 专为计算机或应用使用而设计。
API 在设计中就考虑了安全性，因为它处于中间位置，能够方便地在两个系统之间抽象功能 — API 端点将使用方应用与提供服务的基础架构解耦。 API 调用通常包括授权凭证，旨在降低服务器受到攻击的风险；而且 API 网关可限制访问，从而最大程度减少安全威胁。 此外，在交换期间，HTTP 标头、Cookie 或查询字符串参数为数据提供了额外的安全层。
我们以付款处理服务提供的 API 为例。 客户可以在电子商务商店应用的前端输入银行卡详细信息。 付款处理程序不需要访问用户的银行账户；API 为这笔交易创建唯一的令牌，并将其包含在发往服务器的 API 调用中。 这确保提供更高水平的安全性，抵御潜在的黑客威胁。
无论您是管理现有工具还是设计新工具，都可以通过应用编程接口简化工作。 API 的一些主要优点包括：
改进协作：
企业平均使用近
1,200 个云应用
（链接位于 IBM 外部），其中许多互不相连。 API 支持集成，因此这些平台和应用可以无缝地彼此通信。 通过这种集成，企业可以实现工作流程自动化并增强工作场所协作。 如果没有 API，许多企业将缺乏连通能力，受困于信息孤岛，从而影响生产力和绩效。
促进创新：
API 带来了巨大的灵活性，使企业能够与新的业务合作伙伴建立联系，为现有市场提供新服务，并最终打入可以带来巨大回报并推动数字化转型的新市场。 例如，Stripe 公司最初从一个只有七行代码的 API 起步。 该公司自从与全球众多最大型的企业开展合作之后，提供多元化的产品，包括贷款和"公司卡"，最近的企业估值已达到
360
亿美元（链接位于 IBM 外部）。
数据经济效益：
许多企业选择免费提供 API，至少在最初阶段是如此，这有利于他们围绕自己的品牌建立开发人员受众，并与潜在的业务合作伙伴建立关系。 但是，如果 API 提供对有价值的数字资产的访问权限，那么就可以通过出售这种访问权限获得经济效益（这称为 API 经济）。
AccuWeather
（链接位于 IBM 外部）推出了一个自助式开发人员门户网站，用于销售范围广泛的 API 包，仅用了 10 个月就吸引了 24,000 名开发人员，API 密钥销售量达 11,000 个，同时还建立了一个生机勃勃的社区。
提高安全性：
如上所述，API 会在数据和服务器之间创建一个额外的保护层。 开发人员可以通过使用令牌、签名和传输层安全性协议 (TLS) 加密，通过实施 API 网关来管理和验证流量，以及通过采取行之有效的
API
管理实践，进一步增强安全性。
由于 API 支持企业开放资源访问，同时可保持安全性和控制力，因此它们已成为现代企业中非常宝贵的资产。 以下是您可能会遇到的热门应用编程接口的例子：
通用登录：
一种常用的 API 功能是支持人们使用自己的 Facebook、Twitter 或 Google 个人资料登录详细信息登录网站。 这个便捷的功能支持任何网站使用来自某个比较热门的服务的 API，快速验证用户身份，从而省去为每个网站服务或新会员资格设置新个人资料所花费的时间和麻烦。
第三方付款处理：
例如，目前电子商务网站上无处不在的“使用 PayPal 付费”功能就是通过 API 实现的。 借助这一功能，人们可以在线支付产品费用，而不会暴露任何敏感数据或向未经授权的个人授予访问权限。
旅游预订比较：
旅游预订网站汇总数千个航班，按照不同日期和目的地提供最经济的选择。 这种服务通过 API 实现，可为应用用户提供有关酒店和航空公司可用性的最新信息。 通过自动交换数据和请求，API 可显著减少查看可用航班或住宿所需的时间和精力。
Google 地图：
谈到出色的 API ，一个最常引用的例子就是 Google 地图服务。 除了用于显示静态或互动式地图的核心 API 之外，该应用还利用其他 API 和功能，为用户指路或提供兴趣点。 通过地理位置和多个数据图层，您可以在绘制旅行路线或跟踪移动对象（如送货车辆）时与地图 API 进行通信。
Twitter：
每篇推文都包含描述性核心属性，例如作者、唯一 ID 、消息、发贴的时间戳记和地理位置元数据。 Twitter 向开发人员公开推文和回复，并允许开发人员通过公司的 API 发布推文。
由于 API 支持企业开放资源访问，同时可保持安全性和控制力，因此它们已成为现代企业中非常宝贵的资产。 以下是您可能会遇到的热门应用编程接口的例子：
通用登录：
一种常用的 API 功能是支持人们使用自己的 Facebook、Twitter 或 Google 个人资料登录详细信息登录网站。 这个便捷的功能支持任何网站使用来自某个比较热门的服务的 API，快速验证用户身份，从而省去为每个网站服务或新会员资格设置新个人资料所花费的时间和麻烦。
第三方付款处理：
例如，目前电子商务网站上无处不在的“使用 PayPal 付费”功能就是通过 API 实现的。 借助这一功能，人们可以在线支付产品费用，而不会暴露任何敏感数据或向未经授权的个人授予访问权限。
旅游预订比较：
旅游预订网站汇总数千个航班，按照不同日期和目的地提供最经济的选择。 这种服务通过 API 实现，可为应用用户提供有关酒店和航空公司可用性的最新信息。 通过自动交换数据和请求，API 可显著减少查看可用航班或住宿所需的时间和精力。
Google 地图：
谈到出色的 API ，一个最常引用的例子就是 Google 地图服务。 除了用于显示静态或互动式地图的核心 API 之外，该应用还利用其他 API 和功能，为用户指路或提供兴趣点。 通过地理位置和多个数据图层，您可以在绘制旅行路线或跟踪移动对象（如送货车辆）时与地图 API 进行通信。
Twitter：
每篇推文都包含描述性核心属性，例如作者、唯一 ID 、消息、发贴的时间戳记和地理位置元数据。 Twitter 向开发人员公开推文和回复，并允许开发人员通过公司的 API 发布推文。
目前，大多数应用编程接口都是 Web API ，它们通过互联网公开应用的数据和功能。 以下是四种主要的 Web API 类型：
开放式 API
：这是可通过 HTTP 协议访问的开源应用编程接口。 它们也称为公共 API，具有预先定义的 API 端点以及请求和响应格式。
合作伙伴 API
：这是向战略业务合作伙伴公开或由战略业务合作伙伴公开的应用编程接口。 通常，开发人员可以通过公共 API 开发人员门户网站，以自助方式访问这些 API。 不过，他们仍需要完成加入过程，并获取登录凭证才能访问合作伙伴 API。
内部 API
：这是对外部用户隐藏的应用编程接口。 这些私有 API 不向企业外部的用户提供访问权限，而是旨在提高各个内部开发团队的工作效率和沟通能力。
复合 API
：由多个数据或服务 API 组合而成。 这些服务允许开发人员在一次调用中访问多个端点。 复合 API 在微服务架构中非常有用，在这种架构中，执行单个任务可能需要来自多个来源的信息。
随着 Web API 的使用量不断增加，一些协议被开发出来，为用户提供一组预先定义的规则，以指定可接受的数据类型和命令。 事实上，这些 API 协议推动了标准化的信息交换：
SOAP
（简单对象访问协议）是使用 XML 构建的 API 协议，支持用户通过 SMTP 和 HTTP 发送和接收数据。 借助 SOAP API，可在位于不同环境中或以不同语言编写的应用或软件组件之间轻松共享信息。
XML-RPC
是一种依靠特定格式的 XML 来传输数据的协议，而 SOAP 使用专有的 XML 格式。 XML-RPC 比 SOAP 的出现时间更早，但它更简单，并且由于使用的带宽最少，因此是相对轻量级的传输协议。
JSON-RPC
与 XML-RPC 协议类似，它们都属于远程过程调用 (RPC)，但 JSON-RPC 使用 JSON 而不是 XML 格式来传输数据。 这两种协议都很简单。 虽然调用可能包含多个参数，但预期的结果只有一个。
REST
（具象状态转移）是一组 Web API 架构原则，不同于有协议的标准，REST 没有官方标准。 要成为
REST API
（也称为 RESTful API），接口必须遵守某些架构约束条件。 您可以使用 SOAP 协议构建 RESTful API，但这两个标准通常被视为具有竞争关系的规范。
一个 Web Service 就是一个可以通过 Web 地址访问的软件组件。 因此，根据定义，Web Service 需要网络。 由于 Web Service 公开应用的数据和功能，因此实际上，每个 Web Service 都是一个 API。 然而，并非每个 API 都是 Web Service 。
传统上，API 是指连接到可能使用任何低级编程语言（如 Javascript）创建的应用的接口。 现代 API 遵循 REST 原则和 JSON 格式，通常为 HTTP 而构建，可以形成开发人员友好型接口，这些接口易于访问，并且为使用 Java、Ruby、 Python 和许多其他语言编写的应用所广泛理解。
在使用 API 时，有两种常见的架构方式 — 面向服务结构 (SOA) 和微服务 架构。
SOA
是一种软件设计样式，不同的功能被拆分为各种单独的服务，通过网络提供。 SOA 通常使用 Web Service 实现，可通过标准通信协议访问功能构建块。 开发人员可以从头开始构建这些服务，但一般通过将原有系统中的功能公开为服务接口来创建服务。
微服务 架构
则是另一种架构模式，它将应用划分为较小的独立组件。 将应用作为一组单独的服务，有助于简化测试、维护与扩展。 这种方法在整个
云计算
时代相当常见，支持开发人员处理单独的组件。
虽然 SOA 是应用开发中一个关键的发展步骤，但微服务架构专为扩展而构建，它使开发人员和企业能够灵活敏捷地以更细的颗粒度创建、修改、测试和部署应用，而且迭代周期更短，云计算资源使用效率更高。
要深入了解这些架构方法之间的联系，请参阅"
SOA 与微服务：区别在哪里？
"
