6.2.3 嵌套命名关系
如果仔细看看程序清单 6.3,会发现顶级元素像这样:
{
"_embedded": {
"tacoResourceList": [
...
]
}
}
最值得注意的是 tacoResourceList 这个名称,它源于 List<Resource> 中创建的 Resources 对象实例,虽然不太可能,但是如果将 TacoResource 类名称重构为其他名称,那么 JSON 中的字段名将会需要更改以与之匹配,这可能会破坏任何依赖该名称的客户端。
@Relation 注解可以帮助打破 JSON 字段名与 Java 中定义的资源类型类名之间的耦合。通过在 TacoResource 上使用 @Relationip 注解,可以指定 Spring HATEOAS 应该如何在 JSON 结果中字段的命名:
@Relation(value="taco", collectionRelation="tacos")
public class TacoResources extends ResourcesSupport {
...
}
在这里,已经指定当资源对象中使用 TacoResource 对象列表时,应该将其命名为 tacos。虽然在我们的 API 中没有使用它,但是一个 TacoResource 对象应该在 JSON 中被称为 taco。
因此,从 /design/recent 返回的 JSON 现在看起来是这样的(无论在 TacoResource 上执行或不执行什么重构):
{
"_embedded": {
"tacos": [
...
]
}
}
Spring HATEOAS 使向 API 添加链接变得非常简单明了。尽管如此,它确实添加了几行不需要的代码。因此,一些开发人员可能会选择不在他们的 API 中使用 HATEOAS,即使这意味着如果 API 的 URL 模式发生变化,客户端代码可能会被破坏。
如果在存储库中使用 Spring Data,可能会有一个双赢的方案。让我们看看 Spring Data REST 如何根据第 3 章中使用 Spring Data 创建的数据存储库自动创建 API。
复制链接