【问题标题】:What's the correct way to present paged resources with HAL?使用 HAL 呈现分页资源的正确方法是什么?
【发布时间】:2016-01-11 22:32:22
【问题描述】:

这听起来像是一个菜鸟问题,但我想知道用 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"
        }
    ]
}

}

一切正常,但唯一的问题是返回的集合在_embedded 字段下并且有类名,所以客户端也必须知道这个类名对吗?像非 HAL 格式一样只返回 content 下的集合会更好吗?如果是,我应该如何使用 Spring HATEOAS 实现它?

【问题讨论】:

    标签: hateoas spring-hateoas hal-json


    【解决方案1】:

    这不是问题,_embeddedHAL specification 中是这样定义的。

    users 不是一个类,它是一个链接关系,它允许客户端真正找到它首先要求的集合(例如,使用 JSONPath 表达式)。这根本不是突然出现的东西,但通常是相同的链接关系,客户端用于首先找到该资源。

    假设一个 API 根暴露了这个文档:

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

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

    因此,如果客户端点击名为users 的链接,它可以通过结合有关媒体类型(HAL、_embedded)和服务的知识,在 HAL 响应中的_embedded.users 下找到它正在寻找的实际内容应用程序级语义 (users)。

    【讨论】:

    • 原来我并不完全了解如何正确利用 HAL。非常感谢您的澄清。
    猜你喜欢
    • 2018-08-16
    • 1970-01-01
    • 1970-01-01
    • 2014-03-22
    • 1970-01-01
    • 2012-11-09
    • 1970-01-01
    • 1970-01-01
    • 2019-04-14
    相关资源
    最近更新 更多