应用程序编程接口向开发人员隐藏复杂性，将系统扩展到合作伙伴，组织代码并使组件可重用

API 代表应用程序编程接口，这个概念适用于从命令行工具到企业 Java 代码再到 Ruby on Rails Web 应用程序的任何地方。API 是一种以编程方式与单独的软件组件或资源进行交互的方式。

除非你从头开始编写每一行代码，否则你将与外部软件组件交互，每个组件都有自己的 API。即使你完全从头开始编写一些东西，设计良好的软件应用程序也将具有内部 API 来帮助组织代码并使组件更可重用。并且有许多公共 API 允许你利用通过网络在其他地方开发的功能。

什么是 API？

API 被定义为与软件组件可能交互的规范。这究竟是什么意思？好吧，想象一下汽车是一个软件组件。它的 API 将包括关于它可以做什么的信息——加速、刹车、打开收音机等。它还包括关于如何让它做这些事情的信息。例如，要加速，您将脚放在油门踏板上并推动。

API 不必解释当你踩下油门时发动机内部会发生什么。这就是为什么，如果你学会了驾驶内燃机汽车，你就可以驾驭电动汽车，而无需学习一套全新的技能。API定义中的内容和方式信息结合在一起，该定义是抽象的并且与汽车本身分离。

要记住的一件事是，某些 API 的名称通常用于指代交互规范和与你交互的实际软件组件。例如，短语“Twitter API”不仅指以编程方式与 Twitter 交互的一组规则，而且通常被理解为表示您与之交互的事物，如“我们正在对我们从中获得的推文进行分析” Twitter API。”

API 作为抽象层

说到软件，API 几乎无处不在。API 与计算机科学中最基本的概念之一密切相关：抽象。抽象只是组织系统复杂性的一种方式，以便可以以简单的方式处理复杂的操作。把这种抽象想象成那些淘宝 Dash Buttons，电池供电的按钮电路板，你可以用来从淘宝订购订书钉。这是它们的样子：

你从淘宝订购了一个 Dash Button，并使用智能手机上的应用程序将其与你的 Wi-Fi 网络、你的淘宝帐户和产品（例如你最喜欢的纸巾品牌）相关联。然后，每当你想订购更多纸巾时，只需按下按钮即可。Dash Button 连接到 Internet 并发送消息以在你的帐户上下订单。几天后，纸巾就会送到你家门口。

像 API 一样，Dash Button 是一个非常简单的界面，在幕后隐藏了各种复杂性。你订购的产品的 ID 必须从某个数据库中检索。你的送货地址必须从你的帐户中提取。必须确定最近存放你的纸巾的运营中心，然后通知你从可用库存中移除商品并打包。最后，包裹必须与其他包裹一起通过飞机、卡车和货车的某种组合，以确保所有包裹都能有效地到达目的地。

现在想象一下，作为客户，你必须协调所有这些事情。你永远不会订购纸巾，因为它太复杂和耗时，而且你还有更好的事情要做。幸运的是，整个磨难都离你而去。有一条长长的、相互关联的计算机系统和人工流程链让这些纸巾出现在您家门口，但你只需按下一个按钮即可。

这就是 API 对程序员的意义。它们采用了大量的复杂性，并定义了一组相对简单的交互，您可以利用这些交互，而不是自己全部完成。在任何软件项目中，你可能会直接使用数十个甚至数百个 API，并且这些 API 中的每一个都依赖于其他 API，依此类推。

公共 API 和 API 集成

API 是计算机编程中的一个长期概念，多年来它们一直是开发人员工具集的一部分。传统上，API 用于连接在同一台机器上运行的代码组件。随着无处不在的网络的兴起，越来越多的公共 API（有时称为开放 API）变得可用。公共 API面向外部并可通过 Internet 访问，允许你编写与其他供应商在线代码交互的代码；此过程称为API 集成。**

这些类型的代码混搭允许用户在他们自己的系统上混合和匹配来自不同供应商的功能。例如，如果你使用营销自动化软件 Marketo，你可以将你的数据与 Salesforce CRM 功能同步。

在这种情况下，“开放”或“公共”不应被解释为“免费”。你仍然需要成为 Marketo 和 Salesforce 客户才能使用此功能。但是这些 API 的可用性使集成过程比其他方式简单得多。（InfoWorld有很多您应该了解的公共 API 列表*。）

Web 服务和 API

你可能会想起00 年代早期的网络服务一词，并认为开放 API 的想法听起来非常相似。事实上，Web 服务是一种特定类型的开放 API，它满足一组相当严格的规范，包括用 Web 服务描述语言 (WSDL)（一种 XML 变体）指定的规范。

Web 服务旨在用作面向服务架构 (SOA) 的一部分。正如Nordic APIs 博客所解释的那样，这给 Web 服务带来了坏名声，因为 SOA 从未完全发挥其潜力。用于服务到服务通信的技术的进步——特别是更轻量、更灵活的 REST——也让 Web 服务在公共 API 的世界中有些落后。

REST API

Web 服务最初设计为使用 SOAP（简单对象访问协议）进行通信，这是一种通过 HTTP 发送 XML 文档的消息传递协议。然而，如今，大多数基于 Web 的 API 都使用 REST（具象状态传输）作为架构风格。

REST 由Roy Fielding 在2000 年的博士论文中正式引入。它是一组架构组件、设计原则和交互，用于构建涉及任何类型媒体（文本、视频等）的分布式系统。从本质上讲，REST 是一种构建系统的风格，它允许在网络上灵活地通信和显示信息，同时提供轻松构建通用组件所需的结构。

在 REST API 中，资源几乎可以是任何东西，但示例包括用户、推文列表和推文搜索的当前结果。这些资源中的每一个都可以在资源标识符处进行寻址，在基于 Web 的 REST API 的情况下，该标识符通常是一个 URL。当应用程序使用标识符请求资源时，API以应用程序可以使用的格式（例如 JPEG 图像、HTML 页面或 JSON）将该资源的当前表示交付给应用程序。

REST 的一大区别在于它涉及向发出请求的应用程序发送数据。虽然这提供了极大的灵活性，允许应用程序对数据做任何它想做的事情，但它是以效率为代价的。与在数据所在的位置进行处理然后发送结果相比，通过 Web 发送数据进行处理要慢得多。

当然，“高效”方法的问题在于托管数据的系统需要提前知道应用程序想要用它做什么。因此，为了构建具有通用可用性和灵活性的 API，REST 是必经之路。

API 示例

有许多公共 API 可供您交互，其中许多来自行业巨头。通过 API 以编程方式访问某些平台公司代码的能力使它们成为一个平台，本质上。一些突出的 API 示例包括：

• Google APIs，允许您将代码连接到从地图到翻译的所有 Google 服务。API 对 Google 来说非常重要，以至于他们收购了领先的 API 管理平台Apigee。
• Facebook APIs，允许你以编程方式访问 Facebook 的社交图谱和营销工具。（在 Cambridge Analytica 和其他丑闻的影响下，该公司一直在限制你可以通过这些 API访问的用户数据。）

为了真正了解 API 的工作原理，让我们深入研究两个：Java API，Java 开发人员使用它与 Java 平台交互，以及 Twitter API，一个公共 API，你将使用它与社交媒体交互网络服务。

Java API

Java API 是一个“开箱即用”的软件组件库，可供安装了 Java 开发工具包的任何人使用。这些组件执行常见任务并通常提高生产力，因为程序员不必每次都从头开始。软件中使用的基本组件之一是称为列表的东西，正如您所料，它跟踪项目列表。Java API 定义了您可以对 List 执行的操作：添加项目、对列表进行排序、确定某个项目是否在列表中等。它还指定了如何执行这些操作。为了对列表进行排序，你需要指定列表的排序方式：按字母顺序、数字降序、从最亮到最暗的颜色等。

推特 API

Twitter API 是一个基于 Web 的 JSON API，它允许开发人员以编程方式与 Twitter 数据交互。与 Java 开发工具包中包含的 Java API 不同，Twitter API 是基于 Web 的 API。必须通过 Internet 向 Twitter 托管的服务发出请求来访问它。

使用基于 Web 的 API（例如 Twitter 的），你的应用程序会发送 HTTP 请求，就像 Web 浏览器一样。但是为了人类理解，响应不是作为网页传递的，而是以应用程序可以轻松解析的格式返回。为此存在各种格式，Twitter 使用一种流行且易于使用的格式，称为 JSON。

Twitter 的基本元素之一是推文。Twitter API 告诉你可以用推文做什么：搜索推文、创建推文、收藏推文。它还告诉您如何执行这些操作。要搜索推文，您需要指定搜索条件：要查找的术语或主题标签、地理位置、语言等。

API设计

API 设计师制定 API 的“内容”和“方式”的过程。与可以创建的任何其他事物一样，API 设计中的思考和程度各不相同，从而导致 API 质量的不同程度。精心设计的 API 具有一致的行为、考虑其上下文并牢记用户的需求。

API 中的一致行为极大地影响了它的学习速度以及程序员在使用它时出错的可能性。通常，执行相似操作的 API 的行为应该相似，而不管它们的技术差异如何。举个 API 不一致的例子，让我们看看 Java 中国 List 添加项的两种方式：

即使将项目添加到列表的两种方法做同样的事情，它们的返回类型（boolean 和 void）是不同的。使用此 API 的开发人员现在必须跟踪哪个方法返回哪种类型，这使得 API 更难学习并且其使用更容易出错。这也意味着使用这些方法的代码变得不那么灵活，因为如果你想改变你添加元素的方式，它必须改变。

考虑上下文是另一种形式的一致性，尽管它与 API 外部的因素有关。一个很好的非软件示例是道路规则（右侧交通或左侧交通）如何影响不同国家/地区的汽车设计。汽车设计师在将驾驶员座椅放置在汽车的右侧或左侧时会考虑到环境因素。

在 API 设计中，考虑上下文通常意味着您遵循普遍接受的最佳实践，并从你的用户可能熟悉的其他 API 中汲取灵感。假设你正在构建一个库，该库为 Java 应用程序提供了一种新的 List，可能是专门为处理非常大的列表而设计的。该 List 的 API 可能应该包含一个 add 方法，其行为方式与 Java List add 方法的工作方式相同。这样，用户就可以轻松采用您的库，因为他们已经知道如何使用它。

了解您的用户并牢记他们的需求在 API 设计中至关重要。如果您了解他们的痛点并帮助他们避免这种痛苦，那么你的 API 将拥有快乐的用户。出于同样的原因，你可能会选择打破良好 API 设计的其他规则。如果你正在编写 Web API，那么今天的事实上的标准是使用 JSON 作为交换格式。但是，如果你的 API 将服务于检索大量数据的科学用户，那么 JSON 将过于冗长和繁琐，无法很好地为他们服务。因此，你可能会选择使用像 GRIB 这样的二进制格式，尽管从一般意义上来说这是一个非常不常见的选择。

API 是软件设计的重要组成部分，它们存在于软件堆栈的每个级别。它们提供了一种定义和管理抽象的方法，告诉我们我们可以用软件组件做什么以及我们如何做。设计良好的 API 支持高效、流畅和轻松地采用和使用，而设计不当的 API 往往会在每次使用时引起头痛。

总结

API 是用于构建应用程序软件的一组子程序定义，协议和工具。一般来说，这是一套明确定义的各种软件组件之间的通信方法。

如果本文对你有所帮助，欢迎点赞转发，也欢迎大家说说自己在学习的时候自己的一些心得，方便大家一起学习共同成长！“java架构大仙”阅读更多技术干货文章。