此次我让你完全弄懂 RESTful
本文已收录至 https://github.com/yessimida/yes ，这里有个人全部文章分类汇总，欢迎 star!html
RESTful 想必你们都耳熟能详。git
可是为何要有 RESTful，RESTful 究竟是什么意思。github
为何称之为 RESTful 架构？面试
我不用 RESTful 不行吗？算法
什么样才叫真正的 RESTful ？json
其实网上 RESTful 的文章有挺多的，不过有些讲的糊里糊涂的，并且很大部分都忽略了 HATEOAS。微信
在以前的面试中面试官就问过我，你怎么理解 RESTful 的，英文全称是啥？为何叫这个名字?restful
当时我人都傻了。架构
面试官不讲武德，针对我这个刚出社会的小伙子。app
其实有不少人也稀里糊涂的，也包括我本身。
就面向资源呗，不加动词咯，还能咋滴，我加动词不也能用吗？
并且我以前还特不能理解，为啥这叫架构？
我特地搜索了下架构的解释。
软件架构是有关软件总体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
总体结构与组件的抽象描述。
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 也是修改(新增也是一种修改)，指的是不幂等的操做。
因此根据这些规范咱们都能得知此次交互的一些动做，因此正确的使用姿式以下：
好比获取一个 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 是一种风格，你是否采用这种风格对你的程序运行没有影响，类比驼峰命名来思考。
简而言之，就是不要在 URL 上表现出动做，用 HTTP 动词表明动做，URL 上只作资源，仅此而已。
至于要不要严格遵循 RESTful 风格，我我的的见解是公司内部保持一致就行。
欢迎加我好友进行深刻地交流，备注「进群」，拉你进交流&内推群。
平日的面试题遇到难处，或者看某个知识点翻遍全网的资料仍是感受很模糊、不透彻，能够私聊我，给我留言。
遇到合适的我会整理写出一篇文章，注意这个前提我认为合适的。
那种工做遇到很细节的场景的仍是别了，这种问你上司比较合适：）。
巨人的肩膀
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2
http://www.ruanyifeng.com/blog/2011/09/restful.html
https://stackoverflow.com/questions/671118/what-exactly-is-restful-programming/3950863#3950863
https://en.wikipedia.org/wiki/HATEOAS
更多硬核文章等你来读。
微信搜索【yes的练级攻略】，关注 yes，回复【123】一份20W字的算法刷题笔记等你来领，从一点点到亿点点，咱们下篇见。