🤝2. 协议
作者：Bryan Cooksey 发布日期：2014年4月22日
在第一章中，我们通过形成一个关于API涉及的两个方面——服务器和客户端，来确定方向。对于谁是谁，我们有了扎实的掌握，现在我们准备深入研究这两者之间的通信方式。为了提供背景，我们首先看一下人类的通信模型，并将其与计算机进行比较。之后，我们将进一步讨论API中常用的协议的具体细节。
了解规则
人们制定社交礼仪来指导他们的互动。一个例子就是我们在电话中如何相互交谈。想象一下你和朋友聊天。当他们在说话时，你知道要保持沉默。你知道要给他们一些短暂的停顿时间。如果他们问了一个问题然后保持沉默，你知道他们期望得到回答，现在轮到你说话了。
计算机也有类似的礼仪，只不过它被称为“协议”。计算机协议是一组被接受的规则，规定了两台计算机如何相互交流。然而，与我们的标准相比，计算机协议非常严格。想一想两个句子：“我最喜欢的颜色是蓝色”和“蓝色是我最喜欢的颜色”。人们能够分解每个句子，并理解它们的意思是相同的，尽管单词的顺序不同。不幸的是，计算机并不那么聪明。
为了使两台计算机能够有效地进行通信，服务器必须准确地知道客户端将如何安排其消息。你可以把它想象成一个人询问邮寄地址。当你询问一个地方的位置时，你假设你首先得到的是街道地址，然后是城市、州，最后是邮政编码。你对地址的每个部分也有一定的期望，比如邮政编码应该只包含数字。计算机协议的工作也需要类似的具体规定。
网络协议
几乎每个事物都有相应的协议，每个协议都专门用于不同的任务。你可能已经听说过一些：蓝牙用于连接设备，POP或IMAP用于获取电子邮件。
在互联网上，主要的协议是超文本传输协议，更为人所熟知的是它的缩写HTTP。当你在浏览器中输入类似http://example.com这样的地址时，“http”告诉浏览器在与服务器进行通信时使用HTTP的规则。
由于HTTP在互联网上的普及性，许多公司选择将其作为API的底层协议。使用熟悉的协议的一个好处是降低了开发人员的学习曲线，从而促进了API的使用。另一个好处是HTTP具有多个在构建良好API中有用的功能，我们稍后会看到。现在，让我们勇敢地探索一下HTTP的工作原理吧！
HTTP请求
HTTP中的通信围绕着一个称为请求-响应循环的概念展开。客户端向服务器发送一个请求来执行某些操作。服务器则向客户端发送一个响应，告诉客户端服务器是否能够执行客户端的请求。
为了发出有效的请求，客户端需要包括以下四个内容：
URL（统一资源定位符）
Method（方法）
List of Headers（头部列表）
Body（正文）
这听起来可能是很多细节，只是为了传递一条消息，但请记住，计算机之间的通信需要非常具体。
URL
URL对我们来说是很熟悉的，因为我们每天都在使用互联网，但你是否曾经花时间考虑过它们的结构？在HTTP中，URL是一个事物（名词）的唯一地址。哪些事物会被赋予地址完全取决于运行服务器的业务。他们可以为网页、图片，甚至是可爱动物的视频创建URL。
API进一步扩展了这个想法，包括了像顾客、产品和推文这样的名词。通过这样做，URL成为客户端告诉服务器它想要与哪个事物进行交互的简便方式。当然，API也不称它们为“事物”，而是给它们一个技术名词“资源”。
Method
请求方法告诉服务器客户端希望服务器执行的操作类型。实际上，这个方法通常被称为请求的“动词”。
在API中最常见的四种方法是：
GET - 请求服务器检索一个资源
POST - 请求服务器创建一个新资源
PUT - 请求服务器编辑/更新一个现有资源
DELETE - 请求服务器删除一个资源
举个例子来帮助说明这些方法。假设有一家比萨店提供了一个API供你下订单。你通过向餐厅的服务器发送一个带有订单详细信息的POST请求来下订单，要求他们制作你的比萨。然而，当你发送请求后，你意识到选错了面团类型，于是你发送一个PUT请求来更改它。
在等待订单的过程中，你会发送一系列的GET请求来检查订单状态。等待了一个小时后，你决定已经等够了，于是发送一个DELETE请求来取消你的订单。
Headers
Header（头部）提供有关请求的元信息。它们是一个简单的项目列表，例如客户端发送请求的时间和请求正文的大小。
你是否曾经在智能手机上访问过一个专为移动设备格式化的网站？这是通过一个名为“User-Agent”的HTTP头部实现的。客户端使用这个头部告诉服务器你使用的设备类型，而聪明的网站可以检测到并为你的设备发送最适合的格式。
客户端和服务器处理的HTTP头部有相当多，因此我们将在后面的章节中讨论其他相关的头部。
Body
请求Body（正文）包含客户端想要发送给服务器的数据。继续上面的比萨订购示例，正文就是订单的详细信息所在。
正文的一个独特特点是客户端对请求的这部分具有完全的控制权。与方法、URL或头部不同，HTTP协议对这些部分有严格的结构要求，但正文允许客户端发送任何需要的内容。
这四个部分——URL、 Method、Header和Body——构成了一个完整的HTTP请求。
HTTP响应
在服务器收到客户端的请求后，它会尝试满足请求并向客户端发送一个响应。HTTP响应与请求具有非常相似的结构。主要的区别是，响应中包含状态码，而不是方法和URL。除此之外，响应的头部和正文遵循与请求相同的格式。
Status Codes
Status codes（状态码）是三位数，每个状态码都有唯一的含义。在API中正确使用这个小数字可以向客户端传达很多信息。例如，你可能在互联网上的冒险中见过这个页面：
这个响应背后的状态码是404，表示“未找到”。每当客户端请求一个不存在的资源时，服务器会响应一个404状态码，告诉客户端：“该资源不存在，请不要再请求它了！”
在HTTP协议中还有一系列其他的状态码，包括200（“成功！该请求很好”）到503（“我们的网站/ API当前不可用”）。随着后面的章节的进行，我们将学习更多的状态码。
在响应被发送到客户端之后，请求-响应循环就完成了，这轮通信结束了。现在由客户端发起任何进一步的交互。直到服务器收到新的请求，它不会再向客户端发送任何数据。
API如何构建在HTTP之上
到目前为止，你已经看到了HTTP支持各种各样的排列组合，以帮助客户端和服务器进行通信。那么，这对我们的API有什么帮助呢？HTTP的灵活性意味着基于它构建的API可以为客户端提供很多商业潜力。我们在上面的比萨订购示例中看到了这种潜力。只需对请求方法进行简单的调整，就可以告诉服务器创建一个新订单还是取消一个已存在的订单。很容易将期望的业务结果转化为服务器可以理解的指令。非常强大！
HTTP协议的这种灵活性也延伸到请求的其他部分。有些API需要特定的头部，而其他API需要请求正文中的特定信息。能够使用API取决于知道如何进行正确的HTTP请求以获得所需的结果。
第二章总结
本章的目标是让你对HTTP有一个基本的理解。关键概念是请求-响应循环，我们将其分解为以下几个部分：
请求 - 包括URL（http://...）、方法（GET、POST、PUT、DELETE）、头部列表（User-Agent...）和正文（数据）。
响应 - 包括状态码（200、404...）、头部列表和正文。
在接下来的课程中，我们将在发现API如何依赖这些基本概念来提供强大和灵活性时，重新讨论这些基础知识。
接下来
在下一章中，我们将探讨API在客户端和服务器之间传递的数据类型。
最后更新于