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

Question

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

那么 ATOEAS 带来了什么优势？

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": "john.doe@gmail.com",
  "_links": {

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

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

---

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

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