首页
学习
活动
专区
工具
TVP
发布
社区首页 >问答首页 >具有子级的实体的API版本控制

具有子级的实体的API版本控制
EN

Stack Overflow用户
提问于 2018-10-05 18:06:33
回答 1查看 257关注 0票数 0

我正在将一些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?仅仅是文档,还是背后有某种模式?

EN

回答 1

Stack Overflow用户

发布于 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时,还需要注意以下几点:

  • 根据统一接口约束,URL是标识符(而不是人类可能推断的123 )
  • 您应该使用绝对链接URL,因为相关资源可能不在同一主机上,客户端不应该弄清楚这一点。
  • 虽然常见,但按URL段进行版本控制在这里会导致问题,因为服务器如何知道如何使用适当的版本生成链接?其他方法,如媒体类型、查询字符串,甚至报头都不会受到此影响。归根结底,客户端负责知道要请求哪个API版本。服务器永远不可能知道客户端想要什么。除非服务器保证版本对称性,否则客户端很可能会被绑定到不一致的API版本(例如: Foo 1.0和Bar 1.1)。如果所有API都必须具有相同的受支持版本,即使没有更改,实施版本对称性也可能很困难或很慢。我也见过用来解决网址段问题的网址模板,但是--再说一次--客户端不应该知道或理解模板语法。

希望这可以作为你设计的起点。

票数 0
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/52663182

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档