GraphQL 与 REST HATEOAS 有何异曲同工之处？

via [单页应用的HATEOAS实战 | 洞见](https://mp.weixin.qq.com/s/oeTs3qwRrpzmFdrjjhnGkw)

**更容易让团队找到消除重复的“套路”。**

那么HATOEAS带来了什么优势？

1. 只要客户端总是使用Link Rel来获取URI，那么服务端可以在不破坏客户端实现的情况下实现URI的修改，从而进一步解耦客户端和服务端。
2. 帮助客户端开发者探索API，Links实际上提示了开发者接下来可以进行何种业务操作，开发者虽然精通技术，但往往对于业务不甚了解，这些提示可以帮助他们理解业务，至少是一个查询API文档的好起点。

想象一下，如果某个API的响应中多了一个新的Link，敏感的开发者可能就会询问这个Link是用来做什么的，是一个新的特性吗？虽然看起不起眼，但这往往使两个团队的成员沟通起来更容易。

## 在摸索中前进，自由地重命名你的资源

在项目初始阶段，团队对业务的理解还不深入，很有可能会得出错误的业务术语命名，或者业务对象的建模也不完全合适。

反映在API上，可能你希望能够修正API的URI
采用了HATEOAS的项目中，这很容易，因为客户端是通过Link来查找API的URI，所以你可以在不破坏API Scheme的情况下修改它的URI。

```json
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/hal+json;charset=UTF-8
Transfer-Encoding: chunked
Date: Fri, 05 Jun 2015 02:54:57 GMT

{
 "tracking_id": "123456",
 "status": "WAIT_PAYMENT",
 "items": [
   {
      "name": "potato",
      "quantity": 1
   }
 ],
 "_Links": {
   "self": {      "href": "http://localhost:57900/orders/123456"
   },
   "cancel": {
     "href": "http://localhost:57900/orders/123456"
   },
   "payment": {
     "href": "http://localhost:57900/orders/123456/payments"
    }
 }
}
```

-
Root Resource，它们是API的入口，客户端通过他们浏览当前用户有哪些资源可以访问，你可以定义多个Root Resource，并确保它们的URI不会改变
- Link引入的URI可以自由地变化，可能是因为需要重命名资源，也可能是需要抽取出新的服务（域名变化）

## 消除重复的业务规则校验实现，更容易得适应变化

为了用户体验，可能会要求某些组件根据业务规则展示。例如，对于某个业务对象，要求编辑按钮只在当前用户可以编辑的情况下才展示。

```json
HTTP/1.1 200 OK
Path: /api/userStories/123
{

"author": "john.doe@gmail.com",
"_links": {

"updateUserStory": {
"href": "http://localhost:8080/api/userStories/123" (1)
}

}

}
```

前端会根据 `updateUserStory` link是否出现来验证当前用户是否具有编辑用户故事的能力

---

HATEOAS提倡在响应返回Link来提示对该资源接下来的操作。这种方式解耦了服务端URI，也可以让客户端开发者更容易地探索API。

通过Link来判断业务状态，还能有效地消除单页应用中的业务规则重复实现。

https://diigo.com/0ct6ic