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

@JimmyLv 2018-08-07 15:06:22发表于 JimmyLv/jimmylv.github.io

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": "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