【API】什么是 RESTful ? 看着一篇就够了

RESTful（REST 风格）是一种当前比较流行的互联网软件架构模式，它充分并正确地利用 HTTP 协议的特性，为我们规定了一套统一的资源获取方式，以实现不同终端之间（客户端与服务端）的数据访问与交互。

什么是 REST

说到 REST，我们可能会想到英文单词 rest（意为：休息、放松等），但这里的 REST 实际上是 Resource Representational State Transfer 的缩写，翻译成中文就是“表现层资源表述状态转。

REST 是 Roy Thomas Fielding 博士在 2000 年写的一篇关于软件架构风格的论文中提出的，此文一出，可谓是震惊四方！国内外越来越多的互联网公司都纷纷采用 REST 风格来进行 Web 服务的开发，我们习惯上将使用 REST 风格开发出来的 Web 服务称为 RESTful Web Services，简称 REST 服务。

Fielding 是一个非常重要的人，他是HTTP协议（1.0版和1.1版）的主要设计者、Apache服务器软件的作者之一、Apache基金会的第一任主席。所以，他的这篇论文一经发表，就引起了关注，并且立即对互联网开发产生了深远的影响。
他这样介绍论文的写作目的：
“本文研究计算机科学两大前沿----软件和网络----的交叉点。长期以来，软件研究主要关注软件设计的分类、设计方法的演化，很少客观地评估不同的设计选择对系统行为的影响。而相反地，网络研究主要关注系统之间通信行为的细节、如何改进特定通信机制的表现，常常忽视了一个事实，那就是改变应用程序的互动风格比改变互动协议，对整体表现有更大的影响。我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。”
(This dissertation explores a junction on the frontiers of two research disciplines in computer science: software and networking. Software research has long been concerned with the categorization of software designs and the development of design methodologies, but has rarely been able to objectively evaluate the impact of various design choices on system behavior. Networking research, in contrast, is focused on the details of generic communication behavior between systems and improving the performance of particular communication techniques, often ignoring the fact that changing the interaction style of an application can have more impact on performance than the communication protocols used for that interaction. My work is motivated by the desire to understand and evaluate the architectural design of network-based application software through principled use of architectural constraints, thereby obtaining the functional, performance, and social properties desired of an architecture. )

我们可以从以下 3 个角度来理解 REST。

1. Resource（资源）

当我们把 Web 工程部署到服务器（例如 Tomcat）中之后，那么这个工程中的所有内容在都可以被称为这个服务器中的资源。它可以是一个类、一个 HTML 文件、一个 CSS 文件、一个 JS 文件、数据库中的一张表、一段文本、一张图片、一段音频等等，它们都可以被称为资源。而服务器则可以看作是由许许多多离散的资源组成的。

这些资源都有一个共同的特征，那就是它们都可以通过一个 URI（统一资源标识符） 进行标识，任何对于该资源的操作都不能改变其 URI。想要获取这个资源，只要访问它的 URI 即可。

2. Representation（资源的表述）

资源的表述指的是资源在某个特定时刻的状态的描述，即资源的具体表现形式，它可以有多种格式，例如 HTML、XML、JSON、纯文本、图片、视频、音频等等。通常情况下，服务端与客户端资源的表述所有使用的格式往往是不同的，例如在服务端资源可能是数据库中的一段纯文本、一个 XML 文件、或者是数据库中的一张表，而客户端则可能是表现为 HTML 页面、JSON、甚至是音频和视频。

3.State Transfer（状态转移）

所谓的资源状态转移，简单点说就是，客户端与服务端进行交互时，资源从一种表现形式转换到另一种表现形式的过程。但是 HTTP 协议是一种无状态协议，它是无法保存任何状态的，因此如果客户端想要获取服务器上的某个资源，就必须通过某种手段让资源在服务器端发生“状态转化”，而这种状态转化又是建立在应用的表现层（UI）上的。这就是“表现层资源状态转移”的含义。

REST 实际上描述的是服务器与客户端的一种交互形式，REST 本身并不是一个实用的概念，真正实用的是如何设计 RESTFul（REST 风格）的接口，即我们到底通过什么样的手段让资源在服务器端发生状态转移。

RESTFul

在传统的项目开发中，我们通常都会将操作资源的动词写进 URL 中，而这些动词通常都是我们自行定义的，并没有一个统一的规范。莎士比亚说：一千个人眼中就有一个千个哈姆雷特，这句话应用在这里，再合适不过了。哪怕是对同一资源的相同操作，不同的人所定义的 URL 也是各不相同的。

例如，同样都是通过用户 ID 获取用户信息的请求，其 URL 可能是以下多种形式。

• http://localhost:8080/biancheng/getUserById?id=1
• http://localhost:8080/biancheng/user/getById?id=1
• http://localhost:8080/biancheng/getUserInfo?id=1
• http://localhost:8080/biancheng/a/b?id=1

RESTFul 提倡我们使用统一的风格来设计 URL，其规则如下。

1. URL 只用来标识和定位资源，不得包含任何与操作相关的动词。例如访问与用户（user）相关的资源时，其 URL 可以定义成以下形式。

http://localhost:8080/biancheng/user

2. 当请求中需要携带参数时，RESTFul 允许我们将参数通过斜杠（/）拼接到 URL 中，将其作为 URL 的一部分发送到服务器中，而不再像以前一样使用问号（?）拼接键值对的方式来携带参数，示例如下。

http://localhost:8080/biancheng/user/1

注：我们在 URL 的末尾通过 “/1”的形式传递了一个取值为 1 的参数。

3. HTTP 协议中有四个表示操作方式的动词：GET、POST、PUT 和 DELETE，它们分别对应了四种与资源相关的基本操作： GET 用来获取资源， POST 用来新建资源， PUT 用来更新资源， DELETE 用来删除资源。客户端通过这四个动词，即可实现对服务器端资源状态转移的描述。

资源操作	传统方式 URL	RESTFul URL	HTTP 请求方式
获取资源（SELECT）	http://localhost:8080/biancheng/getUserById?id=1	http://localhost:8080/biancheng/user/1	GET
保存或新增资源（INSERT）	http://localhost:8080/biancheng/saveUser	http://localhost:8080/biancheng/user	POST
修改或更新资源（UPDATE）	http://localhost:8080/biancheng/updateUser	http://localhost:8080/biancheng/user	PUT
删除资源（DELETE）	http://localhost:8080/biancheng/deleteUser?id=1	http://localhost:8080/biancheng/user/1	DELETE

参考：
http://c.biancheng.net/spring_mvc/9675.html
https://www.ruanyifeng.com/blog/2011/09/restful.html