我正在将一些API端点迁移到一种更简洁的方式。但是我有一些关于如何处理嵌套对象的问题。
例如:
我有一个对象Foo
和一个Bar
。
Foo v1.0
{
"field_one": "String",
"field_two": "String"
}
Foo v1.1
{
"field_one": "String",
"field_two": "String",
"field_three": "String"
}
Bar v1.0
{
"foo": "Foo",
"field_one": "String",
"field_two": "String"
}
对于获取Foo
的端点,版本非常简单,是v1.0
还是v1.1
,但是我如何处理Bar
的端点呢?对子节点的每次更改都应该为父节点“生成”一个新版本吗?如果父级有多个版本化的子级,该如何处理?如果Bar
有另一个具有两个不同版本的子Baz
,那么Bar
的版本控制将随子版本的迭代进行吗?
Bar v1.0 -> Foo v1.0
Bar v1.1 -> Foo v1.1
Bar v2.0 -> Foo v1.1 + Baz v1.0
如何让它变得简单?因此,如果消费者想在他的整个应用程序上使用Foo v1.1
,他就知道他应该使用哪个版本的Bar
?仅仅是文档,还是背后有某种模式?
发布于 2018-10-26 05:58:50
所有的评论都对可能的解决方案有一些很好的反馈。你必须要问的问题是,你的嵌套资源是否包含在内。包含不允许对资源进行寻址,因此,它是根据其包含的父级进行版本控制的。例如,考虑一个订单及其相关的行项目。行项目通常不应单独寻址。
如果您有相关但不同的可寻址资源,则任何一种资源都不应直接提供相关资源。这引入了耦合。在REST中解决这个问题的方法是使用HATEOAS。有许多方法可以实现HATEOAS,但只有几个标准提供了指导。关于如何实现HATEOAS没有一个正确的答案,但它可能看起来像这样:
Bar v1.1
{
"field_one": "String",
"field_two": "String",
"links": [
{ "name": "Foo", "href": "http://localhost/foo/123" }
]
}
这使得Bar可以链接到Foo,而不需要依赖于它。这与使用指向相关页面的超链接组成网站的方式相同。
在实现HATEOAS时,还需要注意以下几点:
123
)希望这可以作为你设计的起点。
https://stackoverflow.com/questions/52663182
复制相似问题