什么是RESTful

这篇文章主要讲解了“什么是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”的内容了，经过本文的学习后，相信大家对什么是RESTful这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！