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版本的端点非常简单， isv1.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应该得到哪个版本？只是文档还是背后有一些模式？

4

1 回答 1

0

所有评论对可能的解决方案都有一些很好的反馈。你要问的问题是你的嵌套资源是否被包含。包含不允许对资源进行寻址，因此，它根据其包含的父级进行版本控制。例如，考虑一个Order及其相关的Line Items。行项目通常不应单独寻址。

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

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

于 2018-10-25T21:58:50.030 回答