API，应用程序编程接口（application programming interface）的缩写词，用于从命令行工具到Java、 Ruby on Rails、Web应用等程序。除非你从头开始编写每一行代码，否则你将与外部软件组件进行交互，每个组件都有自己的API。即使你完全从头开始写一些东西，一个精心设计的软件应用程序也会有内部API来帮助组织代码，并使组件可重用性更高。
深入研究一下，API是一个与软件组件交互的规范。例如，如果一辆汽车是一个软件组件，其API将包括有关加速，制动和打开无线电的能力的信息。它还包括有关如何加速的信息：将脚放在加速踏板上并加油。API定义将“what”和“how”信息汇集在一起，它是汽车本身的抽象。
需要记住的一点是，某些API的名称通常用于指代交互的规范以及与之交互的实际软件组件。例如，“Twitter API”这个短语不仅指用于以编程方式与Twitter进行交互的规则集，而且通常被理解为与你交互的内容，例如“我们正在分析从Twitter API获取的推文“。
让我们通过Java API和Twitter API作为示例来深入研究。首先，我们将快速了解这两个API以及它们如何实现“what”和“how”的定义。然后，我们将讨论你何时可能会使用API以及如何进行精心设计API。
Java API
Java API是一个“开箱即用”的软件组件库，可供安装Java开发工具包的任何人使用。这些组件执行常见的任务，通常会提高生产力，因为程序员不必每次都从头开始。软件中使用的一个基本组件是名为List的东西，正如你所期望的那样，它可以跟踪项目列表。Java API定义了你可以对List执行的操作：添加项目，对列表进行排序，确定项目是否在列表中等。它还指定如何执行这些操作。为了对列表进行排序，你需要指定如何排序列表：按字母顺序排列，数字递减排列，最亮至最暗淡的颜色等。
上图为List的排序方法的OpenJDK API文档。comparator是确定列表如何排序的参数。
Twitter API
Twitter API是一个基于Web的JSON API，允许开发人员以编程方式与Twitter数据交互。 与包含在Java开发工具包中的Java API不同，Twitter API是一个基于Web的API。必须通过互联网向Twitter的服务提出请求才能访问它。
通过基于Web的API（例如Twitter），你的应用程序就像Web浏览器一样发送HTTP请求。 但是，网页提供的响应，不是为了人类的理解，而是以应用程序可以轻松解析的格式返回。 为此目的存在各种格式，Twitter使用称为JSON的流行且易于使用的格式。
Twitter中的基本元素之一是推文。Twitter API告诉你可以用推文做什么：搜索推文，创建推文，最喜欢的推文。它还会告诉你如何执行这些操作。要搜索推文，你需要指定搜索条件：要查找的词条或主题标签，地理位置，语言等。
上图是Twitter的Search API文档。在这里，你可以找到查询推文群体所需的所有详细信息，包括可用搜索运算符以及响应格式。
REST API
Twitter API以及许多其他基于Web的API是REST API的一个例子，也就是说它是一种使用Representational State Transfer（REST）架构风格的API。REST是由Roy Fielding于2000年在他的博士论文中正式介绍的，它是一套用于构建涉及任何类型媒体（文本，视频等）的分布式系统的架构组件，设计原则和交互。REST的核心是一种构建系统的风格，它允许跨网络灵活地进行通信和显示信息，同时提供构建通用组件的必要结构。
在REST API中，资源几乎可以是任何东西，示例包括用户，推文列表以及搜索推文的当前结果。这些资源中的每一个资源都可通过资源标识符进行寻址，对于基于Web的REST API，通常是一个URL，例如https://api.twitter.com/1.1/users/show?screen_name=twitterdev。当应用程序使用标识符请求资源时，API会以该应用程序可以使用的格式（如JPEG图像，HTML页面或JSON）将该资源的当前表示形式传递给应用程序。
REST最大的区别之一是它涉及向请求应用程序发送数据。虽然这提供了很大的灵活性，但允许应用程序根据数据执行任何操作，这是以牺牲效率为代价的。通过网络发送数据进行处理相对于进行数据驻留的处理相当缓慢，然后发送结果。当然，“高效”方法的问题在于托管数据的系统需要知道应用程序需要提前做什么。因此，为了构建具有通用可用性和灵活性的API，REST是一条可行的路线。
API作为抽象层
谈到软件，API几乎无处不在。API与计算机科学中最基本的概念之一是并行的：抽象。抽象只是一种组织系统复杂性的方法，以便以简单的方式处理复杂的操作。想象一下这种抽象，就像亚马逊Dash按钮，你可以用它来订购亚马逊的订书钉。这是他们的样子：
上图是亚马逊Dash按钮的几个例子。按下按钮即可订购更多清洁剂或纸巾。
你可以从亚马逊的订购Dash按钮开始，并使用智能手机上的应用程序将其与你的Wi-Fi网络，亚马逊帐户以及产品（例如你最喜爱的纸巾品牌）相关联。然后，只要你想订购更多的纸巾，你只需按下Dash按钮连接到Internet并发送消息以在你的帐户上下订单。几天后，纸巾将抵达你的家门口。
就像一个API，Dash按钮是一个非常简单的界面，隐藏了幕后的各种复杂性。你订购的产品的ID必须从某个数据库中检索。你的收货地址必须从你的帐户中提取。必须确定最近的库存纸巾的履约中心，然后通知从现有库存中取出物品并将其包装。最后，包裹必须通过飞机，卡车和货车以及其他包裹的某种组合来确保所有包裹都能有效抵达目的地。
现在假设作为客户你必须协调所有这些东西，那你绝对不会订购纸巾，因为它太复杂、太费时，而且你还有更多的事情要做。幸运的是，整个考验都是从你身上抽象出来的。计算机系统和人员流程之间存在着长期的相互关联的链条，使得这些纸巾出现在你的家门口，但你只需按下按钮即可。这就是程序员的API，它们解决了大量的复杂性，并定义了一组可以利用的相对简单的交互，而不是自己完成所有工作。在任何软件项目中，你都可能直接使用数十个甚至数百个API，并且每个API都依赖于其他API等。
API设计
API设计是制定API“what”和“how”的过程。与其他任何可以创建的内容一样，API设计中会考虑到不同程度的思考和关注，从而导致API质量水平不同。精心设计的API具有一致的行为，考虑到其背景，并牢记用户的需求。
API中的一致行为极大地影响了它的学习速度以及程序员在使用时出错的可能性。通常，执行类似操作的API应该具有相似的行为，无论其技术差异如何。对于不一致API的示例，我们来看看在Java中将项添加到列表的两种方法：
即使向列表添加项目的两种方法执行相同的操作，它们的返回类型（布尔值和空值）也是不同的。使用此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在每次使用时都会引起头痛。
