通俗易懂讲清 API

在我学习软件开发之前，API 听起来像是一种啤酒（IPA，印度淡色艾尔）。如今我经常使用这个术语，事实上最近我还尝试在酒吧里点了一个 API，结果酒保给了我一个：

404 资源未找到的回应

无论是在科技行业还是其他地方，我遇到很多人对这个相当普遍的术语有着模糊的理解。从技术上讲，API 代表应用程序编程接口，大多数大公司都曾为客户或内部使用构建过 API。但如何用简单的语言来解释 API 呢？除了开发和商业中使用的定义外，是否还有更广泛的含义？首先，让我们退后一步看看网络本身是如何运作的。

1、万维网和远程服务器

当我想到网络时，我会想象一个由连接在一起的服务器组成的庞大网络。互联网上的每个页面都存储在某个远程服务器上。远程服务器其实并不神秘——它只是位于远程计算机中的一部分，专门用于处理请求。

为了更好地理解这个概念，你可以在自己的笔记本电脑上启动一个能够将整个网站提供给互联网使用的服务器（事实上，在将网站发布给公众之前，工程师们就是使用本地服务器进行开发）。

当你在浏览器中输入 www.baidu.com 时，一个请求被发送到 Baidu 的远程服务器。一旦你的浏览器收到响应后，它会解析代码并显示页面。对于浏览器（也称为客户端）来说，Baidu 的服务器就是一个 API。这意味着每次访问 Web 上的页面时，您都与某个远程服务器的 API 进行交互。

API 并不等同于远程服务器——而是指接收请求和发送响应的那部分。

2、将 API 作为服务客户的途径

您可能听说过公司将 API 打包成产品，例如，Weather Underground 出售其天气数据 API 的访问权限。示例场景：

您的小型企业网站上有一个用于给客户预约的表单，您希望让客户能够自动在 Google 日历中创建一个包含该预约详细信息的事件。

API 使用：想法是让您网站的服务器直接与谷歌服务器进行通信，请求创建具有给定详细信息的事件。然后，您的服务器会收到谷歌发回来、处理它并向浏览器发送相关信息（如用户确认消息）。或者，你可以直接通过你自己服务器向谷歌服务器发送 API 请求。

这个 Google 日历 API 与其他远程服务器 API 的区别是什么？

从技术角度看， 区别在于请求和响应格式。 要呈现整个网页，浏览器需要 HTML 格式响应， 其中包含表示代码；而 Google 日历 ****API 调用只返回数据——可能以 JSON 格式返回。

如果你们网站服务端正在发起 API 请求，则意味着你们网站服务端就是客户端（类似于当你使用浏览器导航至某个网站时，浏览器就变成了客户端）。

从用户角度来看，API 允许他们在不离开您的网站的情况下完成操作，大多数现代网站都使用了一些第三方 API。而且，许多问题已经有了第三方解决方案，无论是以库还是服务的形式。通常使用现有解决方案更容易、更可靠。开发团队将他们的应用程序分成多个通过 API 相互通信的服务器并不罕见。为主应用程序服务器执行辅助功能的服务器通常被称为微服务。

总之，当公司向客户提供 API 时，这意味着他们构建了一组专用 URL，返回纯数据响应——也就是说响应中不会包含像图形用户界面（如网站）那样具有表现性负担的内容。你可以用浏览器发起这些请求吗？往往可以。由于实际 HTTP 传输以文本进行， 浏览器会尽最大可能显示响应。

例如，你甚至可以在没有访问令牌情况下直接通过浏览器访问 GitHub API，当您在浏览器中访问 GitHub 用户 API

{
  "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 已经可以在您的代码中使用了。从这段文字中提取数据非常容易，然后您可以随意处理这些数据。

3、A 代表“应用程序”

在结束之前，让我们再举几个 API 的例子。“应用程序”可以指很多东西。以下是 API 语境中的一些示例：

• 具有明确功能的软件。
• 整个服务器、整个应用程序或仅仅是一个小部分的应用程序。

基本上任何可以从其环境中明确区分出来的软件都可以成为 API 中的“A”，并且可能也会有某种类型的 API。 假设您在代码中使用了第三方库，一旦合并到您的代码中，库就成为了您整体应用程序的一部分。作为一个独特的软件，该库可能具有允许与您其他代码交互操作所需 API。

另一个例子：在面向对象设计（Object Oriented Design）中，代码被组织成对象。你们可能拥有数百个已定义好可相互交互操作对象。每个对象都具备 API —— 一套公共方法和属性供它与你们其他对象进行交互操作。此外， 对象内部逻辑也可能设置私密性质， 这意味着它对外界范围隐藏起来（不属于 API）。

通过我们所涵盖内容， 希望大家能够更深入理解 API 的广义概念以及现今常见术语运用方式。