在我学习软件开发之前，我感觉 API 就像一种啤酒。
现在，我经常使用这个术语，以至于我最近尝试在酒吧订购 API。
调酒师的反应是抛出 404：资源未找到。
我遇到了很多在技术领域和其他领域工作的人，他们对这个相当常见的术语的含义理解不太清楚或不正确。
从技术上讲，API 代表应用程序编程接口。在某些时候，大多数大公司已经为其客户或自己内部使用构建了 API。
但是，你如何用简单的语言解释 API？ 还有比在开发和业务中使用的含义更广泛的含义吗？ 首先，让我们回顾一下网络本身的工作方式。
WWW 和远程服务器
当我想到 Web 时，我想到的是连接 服务器 的大型网络。
互联网上的每个页面都存储在远程服务器上的某个位置。远程服务器并不是那么神秘——它只是被优化了以处理请求的远程计算机的一部分。
为了使事情更直观，你可以在笔记本电脑上启动一个服务器，该服务器能够将整个网站服务于 Web（实际上，本地服务器是工程师在向公众发布网站之前用来开发网站的工具）。
当你在浏览器中输入 www.facebook.com 时，请求将发送到 Facebook 的远程服务器。 浏览器收到响应后，将解释代码并显示页面。
对于 浏览器（也称为客户端）而言，Facebook 的服务器是一种 API。这意味着，每次你访问 Web 页面时，你都会与某些远程服务器的 API 进行交互。
API 与远程服务器不同，它是服务器中接收请求和发送响应的部分。
用 API 服务客户
你可能听说过将 API 打包为产品的公司。例如，Weather Underground 出售对其天气数据 API 的访问权。
示例场景：你的小型企业网站上有一个表格，客户用它登录以安排预约。你想让客户能够自动创建带有该预约的详细信息的 Google 日历提醒。
API 的使用：让你的网站的服务器直接与 Google 的服务器通信，并请求创建具有给定详细信息的事件。 然后，你的服务器将收到 Google 的响应，进行处理，然后将相关信息发送回浏览器，例如向用户发送确认消息。
另外，你的浏览器通常可以绕过服务器直接向 Google 服务器直接发送 API 请求。
此 Google 日历的 API 与现有的其他远程服务器的 API 有何不同？
用技术术语来说，区别在于请求和响应的格式。
要呈现整个网页，你的浏览器需要获得 HTML 形式的响应，其中包含演示代码，而 Google 日历的 API 调用只会返回数据（可能采用 JSON 格式）。
如果你的网站的服务器正在发出 API 请求，那么你的网站服务器就是客户端（类似于你使用浏览器浏览到网站时，浏览器就是客户端）。
从用户的角度来看，API 使他们无需离开你的网站即可完成操作。
大多数现代网站至少使用一些第三方 API。
许多问题已经有了第三方解决方案，无论是库还是服务。使用已有的解决方案通常更容易、更可靠。
开发团队将应用程序分解成多个通过 API 相互通信的服务器的情况并不少见。为主应用程序服务器执行辅助功能的服务器通常被称为 微服务。
总而言之，当一家公司向其客户提供 API 时，仅表示他们已经建立了一组专用 URL，这些 URL 返回纯数据响应——这意味着响应将不包含任何你在图形用户界面（如网站）中看到的展示型的内容。
你可以使用浏览器发出这些请求吗？通常情况下，是的。由于实际的 HTTP 传输是以文本形式进行的，因此你的浏览器将始终尽力显示响应。
例如，你可以直接使用浏览器访问 GitHub 的 API，甚至不需要访问令牌。这是在浏览器中访问 GitHub 用户的 API 路由时收到的 JSON 响应（https://api.github.com/users/petrgazarov）：
{ "login": "petrgazarov", "id": 5581195, "avatar_url": "https://avatars.githubusercontent.com/u/5581195?v=3", "gravatar_id": "", "url": "https://api.github.com/users/petrgazarov", "html_url": "https://github.com/petrgazarov", "followers_url": "https://api.github.com/users/petrgazarov/followers", "following_url": "https://api.github.com/users/petrgazarov/following{/other_user}", "gists_url": "https://api.github.com/users/petrgazarov/gists{/gist_id}", "starred_url": "https://api.github.com/users/petrgazarov/starred{/owner}{/repo}", "subscriptions_url": "https://api.github.com/users/petrgazarov/subscriptions", "organizations_url": "https://api.github.com/users/petrgazarov/orgs", "repos_url": "https://api.github.com/users/petrgazarov/repos", "events_url": "https://api.github.com/users/petrgazarov/events{/privacy}", "received_events_url": "https://api.github.com/users/petrgazarov/received_events", "type": "User", "site_admin": false, "name": "Petr Gazarov", "company": "PolicyGenius", "blog": "http://petrgazarov.com/", "location": "NYC", "email": "petrgazarov@gmail.com", "hireable": null, "bio": null, "public_repos": 23, "public_gists": 0, "followers": 7, "following": 14, "created_at": "2013-10-01T00:33:23Z", "updated_at": "2016-08-02T05:44:01Z"}浏览器似乎已经很好地显示了 JSON 响应。这样的 JSON 响应已准备好在你的代码中使用。从此文本中提取数据很容易。然后，你可以对数据进行任何操作。
A 代表 “Application”（应用）
最后，我们再举几个 API 示例。
“应用程序”可以指很多东西。以下是一些与 API 相关的内容：
- 一款功能独特的软件
- 整个服务器，整个应用程序或应用程序的一小部分
基本上，任何可以与环境区别开来的软件都可以是 API 中的 “ A”，并且可能还具有某种 API。
假设你在代码中使用了第三方库，当库被合并到你的代码中，它便成为整个应用程序的一部分。作为一个独立的软件，该库可能会有一个 API，该 API 可以与您的其余代码进行交互。
这是另一个示例：在面向对象设计中，代码被组织为对象。你的应用程序可能定义了数百个可以相互交互的对象。
每个对象都有一个API——一组用于与应用程序中其他对象进行交互的 公共 方法和属性。
对象也可能具有内部逻辑，这是 私有 的，这意味着它对外部作用域（而不是 API）是隐藏的。
希望你通过本文的介绍理解 API 的广泛含义以及当今该术语的更常见用法。
有趣的资源：
原文：What is an API? In English, please，作者：Petr Gazarov