带有子项的实体的API版本控制?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (1)
  • 关注 (0)
  • 查看 (21)

我正在将一些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应该得到哪个版本?只是文档或背后有一些模式?

提问于
用户回答回答于

所有评论都对可能的解决方案有一些很好的反馈。您需要问的问题是您的嵌套资源是否包含在内遏制不允许资源被处理,因此,它根据其包含的父项进行版本控制。例如,考虑订单及其相关的订单项。订单项通常不应单独寻址。

如果您有相关的,但不同的寻址资源,任何一个资源应该直接提供相关的资源。这引入了耦合。在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版本。服务器无法知道客户想要什么。除非服务器保证版本对称,否则很可能客户端将被绑定到不一致的API版本(例如:Foo 1.0和Bar 1.1)。如果所有API必须具有相同的受支持版本,即使没有更改,强制版本对称也可能很难或很慢。我也看过网址模板 用于解决URL段问题,但是 - 再次 - 客户端不应该知道或理解模板语法。

这可以作为您设计的起点。

扫码关注云+社区

领取腾讯云代金券