json - 带有 HAL 和嵌入式资源链接的 HATEOS

问题描述

我认为这个问题的答案很好，因为它解释了很多关于 HAL：如何使用 JSON HAL 处理嵌套资源？

然而，它并没有完全回答这个问题（至少对我来说）。假设我们有一个 /employees 资源，它返回所有员工的列表。我希望员工嵌入，但只提供一些基本信息（而不是全部员工）。根据上述答案和规范，这是可以的。但是我的链接会是什么样子？

那么 _links 会是什么样子呢？让我们简化示例。假设没有分页：

GET /employees

{
    "_links": {
        "self": { "href": "/employees" },
        "employees" { "href": "/employees/{id}", "templated": "true" }
    },
    "_embedded": {
        "employees": [{
            "id": "1",
            "fullname": "bla bli",
            "_links": { ... }
        },
        {
            "id": "2",
            "fullname": "djsjsdj",
            "_links": { ... }
        }]
    }
}

模板化的“员工”URL 是否有意义，或者在这种情况下您不会在 _links 中使用任何条目？如果 URL 正常：模板参数（这里的“id”是否与嵌入的员工对象中的属性匹配？

标签： jsonrestdomain-driven-designhateoashypermedia

我的启发是考虑 HTML 中的类似物——如果它适用于网页，那么它也适用于 HAL。

"employees" { "href": "/employees/{id}", "templated": "true" }

什么是 HTML 模拟？这是一个带有 GET 操作的表单。我们能否在网页上创建一个带有 get 操作的表单，该表单还包含将通过该表单访问的信息的摘要？当然。所以这里应该没问题。

模板参数（此处为“id”）是否必须与嵌入的员工对象中的属性匹配？

我认为没有必要（机器并不关心），但它会让人类的生活更轻松，仅此一项就有价值。

想象一下，如果您愿意，阅读模式的文档，并发现相同的语义概念（员工的标识符）有两个不同的名称，拼写不相关。我猜想这会 (a) 当作者对他们所处的拼写上下文感到困惑时，会在文档中引入可避免的错误，并且 (b) 这种不一致会使我怀疑整个规范的质量。

但是，权衡取舍和其他收益超过这些负债并非不可能。

json - 带有 HAL 和嵌入式资源链接的 HATEOS

问题描述

解决方案

推荐阅读