json - 应该如何从前端处理 Hateoas？

Question

我有这个问题已经在我的脑海里盘旋了一段时间。让我们假设我们已经在不同的层上构建了我们的项目，后端和前端。所以，从前端，我们想要一个客户，它来自 hal+json格式:

GET /customers/1 HTTP/1.1
Accept: application/hal+json
{
    "name": "Alice",
    "links": [ {
        "rel": "self",
        "href": "http://localhost:8080/customer/1"
    } {
        "rel": "transactions",
        "href": "http://localhost:8080/customer/1/transactions"
    }]
}

然后，从前端我想获得所有客户交易。我的问题是:我应该如何获取网址？它应该来自响应吗？还是我应该在内部构建它？

如果我们采用第一个选项，我认为在我们得到我们想要的链接之前迭代所有链接可能并不优雅。此外，可能会出现我们没有想要执行的请求链接的情况。

如果我们选择第二个选项，如果我们实际上没有 id，我不明白如何构建该 url。如果 hatoas 用链接替换 ​​ids 并且我在正文中没有对象引用，我如何创建新的客户交易？

我想也许服务应该同时支持 application/hal+json (面向用户)和 application/json (面向客户)但我不认为这是一般情况下的完成方式。

你怎么认为？

Answer 1

绝对是第一选择。也就是说，由于 HATEOAS 是 Richardson Maturity Model 的最后阶段，客户应该遵循提供的链接，而不是自己构建 URL:

The point of hypermedia controls is that they tell us what we can do next, and the URI of the resource we need to manipulate to do it. Rather than us having to know where to post our appointment request, the hypermedia controls in the response tell us how to do it.

这带来什么好处？我至少能想到两个:

REST API 的简单升级 - 服务器端开发人员可以更改资源的 URI，而不会破坏客户端代码，因为客户端只需遵循提供的链接；此外，服务器端开发人员可以轻松添加新链接

健壮性 - 通过跟踪链接，客户端代码永远不会尝试访问损坏的链接、拼写错误的链接等。

Q: Also, there could happen the situation where we don't have the link of the request we want to do?

API 设计者有责任确保提供所有必需的链接。前端开发人员不应该担心这个。

另见:

Rest lesson learned - avoid hackable URLs