第二章：协议

计算机如何通信

在第一章中，我们通过一张展示API的两端服务器端和客户端的图片了解了API的骨干。通过对这两者直观了解，我们就可以深入了解下这两者是如何通信的。我们首先介绍人类交流的模式，然后和计算机进行对比。随后，我们继续介绍API中使用的一种通用协议的细节。

了解规则

人们创造了社交礼仪来指引他们的交流。一个例子就是我们如何用电话和其他人交流。假设你正和朋友通话。当他们说话的时候，你知道自己应该保持安静。你知道应该允许他们有短暂的停顿。如果他们问了一个问题，然后保持沉默，你知道他们希望得到回应，现在该你说话了。

计算机有相似的礼仪，虽然它们使用的术语是“协议”。计算机协议就是一组已经被接受的规则，这些规则约束计算机如何交谈。然而，和我们的标准相比，计算机协议是非常死板的。花点时间想想这两个句子“我最喜欢的颜色是蓝色”和“蓝色是我最喜欢的颜色”。虽然它们使用的词的顺序是不同的，但是我们可以分解这两个句子并且知道它们的意思是一样的。很不幸，计算机没那么聪明。

为了让两台计算机有效的交流，服务器必须准确的知道客户端会如何排列它的信息。你可以类比一个人询问一个邮件地址。当你询问一个地址的位置时，你假设首先被告知的是街道地址，随后是城市，州，最后是邮政编码。对于地址的每一部分，你也许会有特定的期望，比如邮政编码应该只包含数字。计算机协议要想工作也需要类似的细节。

Web协议

有一个协议是几乎针对一切的：每一个协议完成不同的工作。你可能听说过一些协议：通信设备上用的蓝牙，收邮件的POP或者IMAP。

在Web上，最主要的协议是超文本传输协议，它的缩写更知名一些，HTTP。当你在浏览器中输入http://example.com 这样的地址的时候，“http”告诉浏览器使用HTTP的规则和服务器通信。

由于HTTP在web上无处不在，因此很多公司选择它作为自己的API的底层协议。使用熟悉的协议的一个好处就是可以降低开发者的学习曲线，鼓励他们使用API。另一个好处是HTTP有几个特性对于构建一个好的API非常有用，随后我们会看到。现在让我们擦去迷雾，看一看HTTP是如何工作的吧。

HTTP请求

使用HTTP通信的核心是请求-相应机制。客户端向服务器发送一个请求。相应的，服务器给客户端一个响应，告诉客户端是否可以完成它请求的工作。

图1 请求-响应循环

为了构造有效的请求，客户端需要包含四个部分：

• URL（统一资源定位符）
• 方法
• 首部列表
• 实体

听起来一条信息中包含了大量的细节，但是请记住，计算机之间的通信必须是非常明确的。

URL

由于我们每天使用web，应该非常熟悉URL了，但是你没有花时间想想它的结构呢？在HTTP中，一个URL是一件东西（一个名词）的唯一地址。什么东西应该有地址是由运行在服务器上的商业逻辑决定的。他们可以为web页面、图片甚至可爱的动物的视频指定URL。

API稍微扩展了这个想法，让它包含类似客户，产品和推特这样的名词。这样一来，客户端可以通过URL轻松的告诉服务器它想处理哪个东西。当然，API不会叫它们“东西”，它们有一个专业名词“资源”。

方法

请求方法告诉服务器客户端希望它采取什么动作。事实上，方法通常被认为是一个请求动词。
API中常见的方法有四个：

• GET - 请求服务器获取一个资源
• POST - 请求服务器创建一个新的资源
• PUT - 请求服务器编辑或更新一个已存在的资源
• DELETE - 请求服务器删除一个资源

我们用一个例子帮助理解这些方法。假设有一家可以通过API下单的披萨店。你通过向餐馆的服务器发送包含订单细节的POST请求来下订单，请求他们为你做披萨。然而，发送过请求之后，你发现自己选错了口味，所以你发送一个PUT请求来修改订单。

在等待的过程中，你发送一系列GET请求来检查订单的状态。等了一个小时之后，你觉得自己受够了，于是使用一个DELETE请求取消了订单。

首部

首部提供了请求的元信息。他们是一个简单的项目列表，其中有客户端发送请求的时间和请求主体的大小之类的信息。

你曾经用智能手机访问过专为手机设备设计的网站吗？这可能是通过一个被称为“User-Agent”的HTTP首部来实现的。客户端使用这个首部来告诉服务器你正在使用哪种设备，而且网站也足够智能，可以为你的设备选择最好的格式。

客户端和服务器可以处理很多HTTP首部，我们会在后续的章节中介绍相关的首部。

主体

请求主体包含了客户端希望发送给服务器的数据。继续上面的披萨订单的例子，主体就是订单的细节。

主体的独特之处在于客户端可以完全控制这一部分。对于方法，URL和首部，HTTP协议要求严格的格式，主体则不同，客户端可以发送任何自己需要的东西。

这四个部分——URL，方法，首部和主体——组成了一个完整的HTTP请求。

图2 HTTP请求格式

HTTP响应

当服务器接收到来自客户端的请求后，它尝试完成该请求并且向客户端返回响应。HTTP响应的结构和请求非常相似。主要的不同是没有方法和URL，而是包含了一个状态码。除此之外，响应首部和主体和请求的格式相同。

状态码

状态码一个三位的数字，每一个数字有唯一的含义。在API中正确的使用状态码，这个小小的数字可以向客户端传递大量信息。比如，当你在网上闲逛时可能见过下面这个页面：

图3 默认404页面

这个响应的状态码是404，表示“未找到”。当客户端请求一个不存在的资源，服务器会使用一个404状态作为响应，让客户端知道“这个资源不存在，不要再请求它啦！”

在HTTP协议中还有很多其他状态，包括从200（“成功！请求是正确的”）到503（“我们的服务器/API现在出问题了。”）我们会在随后的章节中学习其中的几个。

当响应发送到客户端之后，请求——响应模式就完成了一次循环，这一轮的交流也就结束了。由客户端来决定是否进行更多的通信。除非服务器接收到一个新的请求，否则不会再向客户端发送任何数据。

图4 HTTP响应格式

如何基于HTTP构建API

到目前为止，我们可以看到HTTP支持一系列的交换来帮助客户端和服务器交谈。那么，这对我们构建API有什么帮助呢？HTTP的灵活性意味着基于HTTP的API可以为客户端提供很多商业上的潜力。我们继续上面披萨订单的例子，来观察其中的潜力。只需改变请求的方法就可以告诉服务器是创建一个新的订单还是取消一个存在的订单。这就可以非常容易的将期望的商业结果转化为服务器可以理解的指示。多强大啊！

HTTP协议的通用性还扩展了请求的其他部分。一些API需要特殊的首部，其他API需要在请求主体中包含特定的信息。是否能够使用API取决于你是否知道如何构造正确的HTTP请求来获得希望的结果。

译自

Chapter 2: Protocols