Question

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

Answer 1

所有评论对可能解决方案都有很好的反馈。您需要问的问题是您的嵌套资源是否包含在中。。包含不允许寻址资源，因此，根据其所包含的父对象对其进行了版本控制。例如，考虑一个 Order 及其相关的订单项。订单项通常不应自行寻址。

如果您拥有相关但不同的可寻址资源，则任何一个资源都应该不直接提供相关资源。这引入了耦合。在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 模板用于解决URL段问题，但是-再次-客户端不必不必了解或理解模板语法。

这可能是您设计的起点。