带有 HAL 和嵌入式资源链接的 HATEOAS答案

【问题标题】：HATEOS with HAL and links to embedded ressources带有 HAL 和嵌入式资源链接的 HATEOAS
【发布时间】：2021-07-17 15:57:13
【问题描述】：

我认为这个问题的答案很好，因为它解释了很多关于 HAL：How to handle nested resources with 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”与嵌入的员工对象中的属性匹配？

【问题讨论】：

标签： json rest domain-driven-design hateoas hypermedia

【解决方案1】：

我的启发是考虑 HTML 中的类比 - 如果网页可以，那么 HAL 也可以。

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

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

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

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

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

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

【讨论】：