RESTful 想必大家都耳熟能详。

但是为什么要有 RESTful，RESTful 到底是什么意思。

为什么称之为 RESTful 架构？

我不用 RESTful 不行吗？

什么样才叫真正的 RESTful ？

其实网上 RESTful 的文章有挺多的，不过有些讲的糊里糊涂的，而且很大部分都忽略了 HATEOAS。

在之前的面试中面试官就问过我，你怎么理解 RESTful 的，英文全称是啥？为什么叫这个名字?

当时我人都傻了。

面试官不讲武德，针对我这个刚出社会的小伙子。

其实有很多人也稀里糊涂的，也包括我自己。

就面向资源呗，不加动词咯，还能咋滴，我加动词不也能用吗？

而且我之前还特不能理解，为啥这叫架构？

我特意搜索了下架构的解释。

软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

整体结构与组件的抽象描述。

RESTful 哪有什么组件和结构之间的玩意？

所以就至今我写下这篇文章的时候我也理解不了为什么叫 RESTful 架构。

可能是我对架构的理解太狭隘，还不到火候。

我个人只能理解成 RESTful 风格的 API 设计，也就是说 RESTful 只是一种指导风格，就像我们 Java 要用驼峰命名法。

那不用驼峰命名法代码就不能跑了吗？

当然能跑，这只是一种希望大家都能遵循的规范。

对 RESTful 而言我觉得算不上规范，只能说指导风格。

来让我们正式的进入对 RESTful 的剖析。

REST

REST 不是一个单词，是 Representational State Transfer 的缩写。

直译过来就是表述性状态转移。

我对这个名字蒙了一年多，就不能说点能听得懂的嘛。

从提出 REST 的论文中我翻了翻，没有明说但是表达的意思是其实它还有个主语 Resource 。

所以是资源的表述性状态转移。

稍微可以理解一点了。

我们先不管什么状态转移，大致先有点感觉。

知道 REST 之后 RESTful 就不难解释了，加 ful 就是变形容词了，比如 wonderful girl。

至此对名字稍微解释了一下，疑惑还在没事，咱们慢慢理。

REST 的核心

核心就是资源，用 URL 定位资源，用 HTTP 动词来描述所要做的操作。

HTTP的提供了很多动词：GET、PUT、POST、DELETE……

这些动词都是有含义的。

比如 GET 就是获取资源，是查询请求。

PUT 指的是修改资源，是幂等的。

POST 也是修改(新增也是一种修改)，指的是不幂等的操作。

所以根据这些规范我们都能得知这次交互的一些动作，所以 RESTful 风格正确的使用姿势如下：

比如获取一个 user。

错误姿势：GET /getUserById?userId=1。

正确姿势：GET /users/1。

再比如新增 user。

错误姿势：POST /addUser （省略body）。

正确姿势：POST /users （省略body）。

可以看到 HTTP 的动词其实就能指代你要对资源做的操作，所以不需要在 URL 上做一些东西，就把 URL 表明的东西看作一个资源即可。

这里注意要用对 HTTP 动词，比如一个获取资源的请求用 PUT，用了也能获取资源但是这不合适。

其实更深一步的理解是  HTTP 是一个协议。

协议其实就是约定好的一个东西，协议就规定 GET 是获取资源，那你非得在 URL 上再重复一遍或者所有请求不论增删改都用 GET 这个动作，这其实就是没有完全遵循这个协议。

可以说只是把 HTTP 当成一个传输管道，而不是约定好的协议。

这其实是对 HTTP 更深一层的认识，我认为也是 RESTful 被推出的原因。

当然理想很丰满，现实很骨感，还是有很多人就 getUserById。

不过我个人觉得问题不大，公司统一就行。

HATEOAS

即 Hypermedia as the Engine of Application State 的缩写，翻译过来就是作为应用状态引擎的超媒体。

这也是 REST 提出的设计。

是不是理解不了？其实很简单。

例子我就不自己编了，抄一下 stackoverflow 回答上的例子。

比如你请求获取用户列表：

GET /users
Accept: application/json+userdb

此时的返回应该是：

200 OK
Content-Type: application/json+userdb

{
    "users": [
        {
            "id": 1,
            "name": "Emil",
            "country: "Sweden",
            "links": [
                {
                    "href": "/user/1",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/1",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/1",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        },
        {
            "id": 2,
           ....省略.....
        }
    ],
    "links": [
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

重点就是这个 links，结果会返回你能对这个资源所做的操作。

比如对于 userId 是 1 的，你调用PUT /user/1就是做修改这个用户，DELETE /user/1就是删除这个用户。

最外层的 links 告诉你用 POST /user 就能再创建一个用户。

这里还有个隐藏信息，可以看到外层的 links 没有返回 DELETE 的信息，说明此时客户端无法删除用户！

所以说 RESTful API 还需要再返回此时能对资源做的操作，这样客户端就知道它能做什么。

它也不需要管具体怎么做，反正返回里面会告诉它 DELETE 就这样这样，POST 就这样这样。

没告诉它的就是不能做的。

然后这个时候再去理解下资源的表述性状态转移，是不是感觉来了？

如果说上一 part 提到用 HTTP 的动词来指代动作， URL 仅表示资源的现实是骨感的。

那么 HATEOAS 的现实就是骨灰。

基本上没几家公司会这么做。

就我个人而言这玩意没啥用。

它的出发点是让客户端从响应就能得知对资源操作的入口，并且通过响应得知哪些动作能执行。

听起来好像有点用，但是就我目前的功力，我只能看到响应变得十分冗余。

最后

这篇文章关于 RESTful API 具体的写法我就提到一些，还有挺多的就自己查资料吧。

文章的目的是为了让你理解 RESTful API，我再总结一下重点。

HTTP 是协议，不是传输通道。（对协议不理解的看我之前的 HTTP 分析）

所以协议约定了很多东西，推荐我们按照协议的用法进行客户端和服务端的交互。

也就是 RESTful 表明的面向资源，通过 HTTP 动作 + URL 上的资源。

RESTful 还提到了 HATEOAS，虽说基本上没什么公司会这样使用，但是它能让你更好的理解 REST 这个名字的含义。

RESTful 是一种风格，你是否采用这种风格对你的程序运行没有影响，类比驼峰命名来思考。

简而言之，RESTful 就是不要在 URL 上表现出动作，用 HTTP 动词代表动作，URL 上只做资源。

仅此而已。

至于要不要严格遵循 RESTful 风格，我个人的看法是公司内部保持一致就行。

那种工作遇到很细节的场景的还是别了，这种问你上司比较合适。