进行微服务 REST API 版本控制的最佳方法是啥？

Posted 2023-03-15

【中文标题】进行微服务 REST API 版本控制的最佳方法是啥？

【英文标题】：What is the best way to do microservice REST API versioning?进行微服务 REST API 版本控制的最佳方法是什么？

【发布时间】：2018-11-23 18:07:04

【问题描述】：

我正在使用 Spring 开发这个项目并在 AWS EC2 实例中托管。由于很少有新的需求出现，我不得不更改我的 API 合同。但我不想破坏当前的客户。所以，我正在尝试使用版本控制来实现一些 REST API。这样每当我更新端点时，消费者应用程序就不会崩溃。但我对如何进行 API 版本控制感到困惑。我想到了两种方法。

在同一服务器中创建下一个版本端点，（在春季使用 RequestMaping("/v1/api1"),RequestMaping("/v2/api1") 类似的东西。）

李>

其他明智的做法是在新服务器实例中完全运行 v2 API，但保留相同的 API 端点足迹并使用 AWS APIGateway 作为代理并在那里配置版本控制，然后根据版本号路由到旧服务器和新服务器在请求中。

但我相信第一种方法会导致大量代码重复和代码管理混乱。因为我们通过变体保持相同的功能。

在第二种方法中，如果我的版本增加，我必须为机器人版本保留两组实例，然后很难管理这些实例，特别是当我将拥有大约 15 个微服务实例时。而且它也不具有成本效益。因为我的公司是一家初创公司，所以我也需要考虑这个事实。

关于 API 版本控制和管理多个版本的端点是否有任何最佳实践？我愿意接受任何建议和指导。如果多台服务器也是解决方案，我愿意重新考虑成本限制。我需要这个问题的最佳解决方案。

【问题讨论】：

As few new requirements coming up, I have to change my API contracts. But I don't want to break the current clients. - 一个完美的迹象表明您的 API 只是进一步的 Web RPC API 交换任意 JSON 消息并错误地将其称为 REST 而没有实现 REST 原则。根据"Uncle" Bob Martin，Web 只是一种交付机制，架构是关于意图，而 REST 的意图是将客户端与服务器分离，从而使错误变得健壮且灵活地适应变化.

实际上客户端由于客户的要求，现在需要在响应中修改位数据结构。所以我们必须修改我们的 API 以匹配它，这就是我想要一个新版本的原因。指出如果我们考虑端点，版本化的 API 无论如何都是不同的 API。这就是我们计划版本控制的原因。

您的 API 必须以何种方式更改才能返回 a bit modified data structure？通常表示格式应在客户端和服务器之间协商。客户端可以通过发送Accept 标头来表达它支持的表示形式，然后服务器选择它能够提供服务的表示形式（也考虑顺序和最高质量因素）。理想情况下，客户会发送application/vnd.some-doctype-format+json; version=2 或类似内容的协商请求。如果您查看 html，它会在 text/html 中定义版本，即保持向后兼容

【参考方案1】：

第一个问题是为什么需要新版本？ 您的合同是否发生了变化，或者内部逻辑是否发生了一些变化，以及您是否真的需要公开一个新版本。下一个要问的问题是您需要支持旧版本多长时间以及您打算拥有多少个版本。 对于成熟的 api，您可以使用方法 2，如果可能的话，占用空间更小。对于其他人，您将处于更好的情况下通过相同的服务公开 v2 并解决它。 代码复制是一个因素，但取决于您更改的内容。如果只是关于合同变更，您可以尝试使用相同的业务逻辑并使其适用于新旧合同。

这里有一些你可能会觉得有用的链接

https://www.mnot.net/blog/2012/12/04/api-evolution

Best practices for API versioning?

【讨论】：

感谢您的回复。是的，我的 API 合同发生了变化。我也相应地更新了我的问题。