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

[JimmyLv]

via 单页应用的HATEOAS实战 | 洞见

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

那么HATOEAS带来了什么优势？

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

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

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

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

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

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可以自由地变化，可能是因为需要重命名资源，也可能是需要抽取出新的服务（域名变化）

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

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

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

  "author": "[email protected]",
  "_links": {

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

  } 

}

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

---

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

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

https://diigo.com/0ct6ic