使用 HAL 呈现分页资源的正确方法是什么？

Question

这听起来像是一个菜鸟问题，但我想知道用 HAL 格式呈现分页资源的最佳方式是什么？现在我正在使用 Spring HATEOAS API 将 Page 对象转换为资源 PagedResourcesAssembler#toResource(Page<T>, ResourceAssembler<T,R>)。这导致以下输出：

{
"_links": {
    "self": {
        "href": "http://example.org/api/user?page=3"
    },
    …
}
"count": 3,
"total": 498,
"_embedded": {
    "users": [
        {
            "_links": {
                "self": {
                    "href": "http://example.org/api/user/mwop"
                }
            },
            "id": "mwop",
            "name": "Matthew Weier O'Phinney"
        }
    ]
}

}

一切正常，但唯一的问题是正在 returned 的集合在 _embedded 字段下并且具有 class 名称，因此客户端必须知道这个 class 名字也对吧？像非 HAL 格式那样只 return content 下的集合会更好吗？如果是，我应该如何使用 Spring HATEOAS 实现它？

Answer 1

这不是问题，_embedded 在 HAL specification 中是这样定义的。

users 不是 class，它是 link 关系，它将允许客户端实际找到它首先要求的集合（例如使用 JSONPath 表达式).这根本不是突然发生的事情，但通常是相同的 link 关系，客户端过去常常首先找到该资源。

假设一个 API root 暴露了这个文档：

{
  "_links": {
    "users": {
      "href": "…"
    },
    …
  }
}

看到这一点，客户端必须知道 users 的语义才能找到它想要遵循的 link。在您的情况下 users 基本上指向支持分页的集合资源。

因此，如果客户端遵循名为 users 的 link，则它可以结合有关媒体类型的知识，在 HAL 响应中的 _embedded.users 下找到它要查找的实际内容(HAL, _embedded) 和服务的 application-level 语义 (users).

使用 HAL 呈现分页资源的正确方法是什么？

What's the correct way to present paged resources with HAL?

hateoas

spring-hateoas

hal-json