3

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

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

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

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

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

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

4

1 回答 1

3

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

以下是一些您可能会觉得有用的链接

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

API 版本控制的最佳实践？

于 2018-06-14T08:15:43.340 回答