如何从前端处理仇恨？

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.如果hateoas用链接替换id并且我还没有身体中的对象引用,我怎么能创建新的客户交易呢？

我认为也许服务应该同时支持 application/hal+json(面向用户)和application/json(面向客户端),但我不认为这是如何一般地完成它.

你怎么看？

Answer 1

绝对是第一选择。也就是说，由于 HATEOAS 是Richardson 成熟度模型的最后阶段，因此客户应该遵循提供的链接，而不是自己构建 URL：

超媒体控件的要点是它们告诉我们接下来可以做什么，以及我们需要操作的资源的 URI。我们不必知道在哪里发布预约请求，而是响应中的超媒体控件告诉我们如何去做。

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

• REST API 的简单升级 - 服务器端开发人员可以更改资源的 URI，而无需破坏客户端代码，因为客户端只需遵循提供的链接即可；此外，服务器端开发人员可以轻松添加新链接
• 稳健性 - 通过跟踪链接，客户端代码永远不会尝试访问损坏的链接、拼写错误的链接等。

问：另外，可能会出现我们没有我们想要做的请求的链接的情况？

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

也可以看看：

• 吸取的教训 - 避免可破解的 URL