用啤酒和乐高解释什么是API
API是我们一直都在使用的东西。尽管他们无处不在，但许多人 - 甚至是技术人员对API是什么以及工作方式都有一个非常模糊的理解。说真的，你可以请你的同事快速解释API，他们一般告诉你：“API代表应用程序编程接口。它是一个能让软件应用程序彼此通信的接口......“，如果这样解释的话，大多数人真的无法真正地理解它。
对于前端人员或其他业务人员，API是一个黑盒子，我们如何解释给他们听呢？
API中“A”是应用App的意思
这个A就是严重依赖于上下文的，需要根据具体的使用案例确定，“应用程序App”实际上可以指代很多东西：整个服务器、整个App本身及其所需的数据，或者只是App的一小部分。
如果在浏览器栏中输入www.github.com，Chrome（或Firefox或Safari）会向GitHub的服务器发送请求，该服务器会礼貌地发回在本地计算机上显示的页面及其内容所需的所有代码。当你的浏览器收到此响应时，它会解释代码并显示该页面。
1. 服务器作为API：对于你的浏览器（也称为客户端），GitHub的服务器是一个API。这意味着每次访问Web上的页面时，都会与某些远程服务器的API进行交互。此上下文中的API与远程服务器不同，相反，它是服务器的一部分，它接收请求并发送响应。
2. 整个应用App作为API：在初始调用时，GitHub服务器发送整个Web应用程序：结构外观（站点的布局，它的外观），包括网站的所有内容。显示部分作为HTML代码发送，由浏览器呈现。内容 - 网站中包含的动态信息 - 以数据形式发送，通常采用JSON格式，然后在页面上的适当位置呈现。
因此，如果我们正在浏览一个典型的GitHub页面，那么显示部分 - 比如顶部的导航栏，左边的用户照片和生物照片，中间固定的存储库 - 这些部分几乎保持不变，但那些代表GitHub每天活动水平的绿色小方框是什么？这会根据用户的贡献而变化，当我们将项目推送到GitHub时，然后去检查个人资料页面时，API会告诉我们的浏览器为今天为方形绿色小块，但是，其他一切都保持不变。
不同类型的API允许我们的浏览器调用特定类型的信息并更新相关的数据位 - 而不需要重新加载所有其他没有改变的东西。
3. App的一部分作为API：在已经有的库包基础上构建Web应用会更快更容易（并且通常更可靠）。这个库包可能是某个* -As-A-Service的方式。
但是这些组件如何相互通信，以便作为一个统一的App一起执行？
“P”表示协议Protocol，“I”表示接口Interface
API的应用程序端可能有很大差异，但无论我们谈论什么上下文下API，API的最终工作目的都是相同的：沟通和协调。
API中的“P”指的是该软件与其他软件商定的一种通讯方法。
API中的“I”接口是指API的中间部分，使得两个应用程序能够相互通信的实际功能。
因此，从根本上说，API可以被认为是两种软件之间的一种协议或契约，即“胶合层”，使得它们能够进行接口和协同工作，本质上，API说，“如果你给我这个指令，我将执行此操作/返回此信息。”
打个比喻：
API就像啤酒厂的啤酒水龙头。每个水龙头对应一种特定类型的啤酒，所以当你拉动标有“波特Porter”的水龙头把手时，你就会知道你的玻璃杯里装满了浓郁的大麦香味啤酒，而“皮尔森Pilsner”则会带来一种清爽的黄色啤酒。
类似相同的方式，请求API输出的客户端知道哪些数据可以“敲击”它并获得所需的输出。同时，用户甚至不需要知道或关心水龙头内部发生的情况。你可以重新排列行或优化您的产品（您正在服务的brew或app），而不会影响您的用户，因为接口保持不变。
API不仅会输出数据，他们也接受数据。这里我们的啤酒比喻就不起作用了，因为啤酒只有一种方向的流动。因此，让我们混合我们的比喻来说明数据如何进入API。
幼儿玩具中有一种形状分类玩具，形状像圆形，星形和三角形的小块只有通过适当形状的开口孔才能插入; 一颗恒星只能通过星形孔进入。在API中，数据以定义的形式（例如圆形或三角形等）提供，并且只能通过相应的开口才能进入接口，API期望某种格式数据，并拒绝不合适的数据，不要试图将三角形数据放入方孔中。因此，客户被迫根据API构建者的规范组织输入。
无论我们使用什么比喻来解释它，API都可以被认为是两个软件之间的协议或契约：“如果你给我这个指令，以这种方式格式化，我将执行这个指定的动作或返回此信息。“
API作为产品
API除了作为浏览器、服务器、软件和数据库之间信息交换的载体之外，还可以作为产品进行打包和销售。例如，Weather Underground(安卓手机默认天气预报App)出售对其天气数据API的访问权限，这是一组返回纯数据响应的专用URL，在这种情况下，这些数据是最新的天气预报，供你链接并可在你自己的应用程序中提供数据。你得到这些API提供的数据以后，可以自己构建自己的图形用户界面来显示展示。
也就是说，你绝对可以使用浏览器向API发出请求，并查看结果数据，只是没有图形界面。由于请求数据实际是以HTTP传输并通过文本形式输出，因此你的浏览器通常能够呈现响应。例如，你可以直接使用浏览器访问GitHub的API，甚至无需访问令牌，一般是JSON数据格式的响应，比如GitHub的API响应：
|
总结
API可以是几乎任何东西，真的。服务器，应用程序，甚至是要买卖的产品。这就是为什么后端人员很难解释，即使是我们这些每天与他们一起工作的人。
也许定义API本质的最恰当的方法是使用乐高Legos。乐高积木通过一个块上的凹凸系统相互连接，这提供了一种简单且结构化的方式，允许所有部件以相同的方式拼接在一起。与此同时，可能的组合形式是无止境的。
Legos确实是了解开发人员API的有用方法。使用API，开发人员无需在每次编写新程序时从头开始。他们不再需要构建一个试图做所有事情的核心应用程序；相反，他们可以通过使用已经创建好的API来更好地完成工作，并承担某些责任。所以API是软件开发的乐高积木：软件与其他软件通信的标准化工具，可以加快构建和部署。幸运的是，每个人的加载时间都更快。