0. 前言

上一篇文章讲了 HTTP 的一些基本知识，今天我们来聊聊 RESTful API 这个概念。

HTTP 入门

RESTful API 是什么？

RESTful API，顾名思义，包含三个部分：

1. API
2. REST
3. RESTful - 形容词，像 REST 一样的

我们下面就来逐一讲解一下。

1. API 是什么？

API 是 Application Programming Interface 的简称，中文名：应用程序接口。

如何理解接口呢？简单来说，接口 = 两个程序之间的沟通方式。

A 程序想要给 B 程序发送信息，A 程序就需要通过 B 程序的接口来传输数据。

B 程序从接口接受到信息之后，进行内部的消化处理，可以返回一个 A 程序期待的结果。

这里的重点是：B 程序需要告诉 A 程序，我能接受的信息格式是怎么样的，我会返回什么样的东西给你。

这么一来，A 就知道应该在什么情况下可以找 B，以及需要的时候要如何和 B 沟通。

2. REST & RESTful

REST 全称为 REpresentational State Transfer，中文：表现层状态转换。

REST 是一种软件的架构方式（Software Architectural Style），它定义了一系列的规则，这些规则是用来创建 Web Service（网络服务）的。

符合 REST 规则的 Web Service，就叫做 RESTful Web Service。

听到这里，你可能要问，Web Service 跟 API 又有什么区别啊？我们讲的不是 RESTful API 吗？怎么又来了个 RESTful Web Service？

事实上，Web Service 就是帮助两个程序通过网络沟通的服务，也可以理解为网络版的 API，总之就是为了让程序之间能互相听懂对方在讲什么，达到传输信息，获取信息的目的。

RESTful Web Service = RESTful API

那……REST 有什么规则呢？

注意： REST 架构跟 HTTP 协议一样，也用到了 Client-Server 这个架构。 服务器是提供资源的，客户端是要找服务器拿资源的。

1. 统一接口（Uniform interface）：所有想要跟我说话的人都必须通过同一个接口，我对大家一视同仁；
2. 客户端服务器分离（Client-Server Separation）：客户端和服务器是完全独立行动的，它们唯一的互动方式就是通过 API 聊天，客户端发出请求（request），服务器进行回复（response）；
3. 无状态（Statelessness）：服务器不认识客户端，每次聊天（request）都是一个独立的对话，所以客户端每次来聊天的时候必须把所有必要的信息都带着；
4. 资源可缓存（Cacheable resources）：服务器的回复必须明确表明“我这个回复你可以存着/不能存着”，假如服务器说可以存，那么这个回复必须要有版本号 Version Number，这样客户端就不需要一直追着服务器要相同的回复了（减少重复沟通）；
5. 系统分层（Layered System）：在服务器和客户端之间可能会有多个中间层（传话的），但是传话的人不能擅自更改客户端的请求，也不能修改服务器的回复，传话的必须要保持公正公平；
6. 根据需要编程（Code on demand）：**这条不是必须要符合。**在必要的情况下，服务器的回复可以带着可执行的代码（比如 HTML 里面带一段 JavaScript 代码），客户端可以执行服务器带来的代码。

满足 REST 6 大定义的前 5 条的 Web Service，都可以算是 RESTful API。

等等……资源是什么？

资源可以简单理解为数据。

比如你打开一个网页，打开一个图片，听一首歌，这些都是数据。

在 REST 里面，每个资源都是用一个唯一的名称来表示的（URI - Uniform Resource Identifiers），通过 URI 就可以找到你想要的资源。

资源/数据的表现形式是多种多样的，比如图片可以有 png，jpeg；歌曲则是 mp3、wmv 等。

REST 的全称，Representational State Transfer，里面的 Representational，指的就是资源的表现形式。

State Transfer 一词体现了资源的可变性，我们之前说到 Cacheable 的时候，资源是可以携带版本号，被客户端缓存的。客户端缓存的这个资源，就是服务器传来的 State，而 State 是灵活可变的。服务器只负责传输资源的每个状态，不需要考虑资源之前和之后的状态（活在当下的服务器啊~~）。

URI 又是什么？？跟 URL 有点像啊……

URI 是 Uniform Resource Identifiers 的简称，URI 包含了 URL + URN。

URL 全称是 Uniform Resource Locator，中文：网址。

URL 是网络的重要组成概念之一，URI 是统一资源标识符，URL 是一种特殊的 URI；URI 只是给了资源一个身份，而 URL 还可以让我们通过网址直接获取资源。

URL 这里就不具体展开啦~ Ref: URI 与 URL 的区别

3. 关键概念

希望你看到这里还没有晕掉~我们来整理一遍 RESTful API 的关键概念吧。

下面这张图简要解释了这些概念之间的关系，从这张图里，我们可以发现一个很有趣的事实，那就是：

我们之前讲的 HTTP 这个协议其实跟 RESTful API 没有任何关系；一个不用 HTTP 协议的，满足 REST 规定的 Web Service，依然是一个 RESTful API。

4. RESTful API 常见问题

1. RESTful API 和 JSON 的关系

有人会问，RESTful API 是不是都用 JSON 格式交换啊？

关于这个问题，我们首先要回到 REST 的架构定义，REST 并没有把数据交换的格式限制为 JSON，所以我们也可以在 RESTful API 里面用 HTML、XML、plain text 来进行数据交换。

2. RESTful API 跟 HTTP 真的没关系吗？

虽然 HTTP 和 RESTful API 不存在绑定的关系，但是绝大多数的 RESTful API 都是通过 HTTP 协议传输的。

巧的是，HTTP 协议也是活在当下的（stateless），每次请求都是独立的，于是这两个性情相投的小伙伴一拍即合。

99% 的情况下，人们提到 RESTful API，传输协议就默认为 HTTP，也就是基于 HTTP 传输的 RESTful API。

5. 结语

今天这篇文章主要讲了：

1. API 是什么 - 接口：两个程序之间的沟通方式
2. REST 是什么 - 一种软件的架构方式，定义了 Web Service 的规则
3. Web Service - 网络版的 API，让程序联网沟通
4. REST 的 6 大规则 - 满足前 5 个的 Web Service 就算 RESTful API
5. RESTful Web Service = RESTful API
6. REST 资源 - 用 URI 来标识
7. URI 和 URL 的区别 - URI 包含 URL
8. RESTful API 不一定要用 JSON 进行数据交换
9. RESTful API 和 HTTP 的关系 - 本质上毫无关联，但实际上大部分 RESTful API 都基于 HTTP 协议传输。

希望对大家有所帮助~