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 风格，我个人的看法是公司内部保持一致就行。
巨人的肩膀
www.ruanyifeng.com/blog/2011/0…
stackoverflow.com/questions/6…
