我正在使用Spring开发此项目并在AWS EC2实例中托管。由于很少有新的要求出现，我必须更改我的API合同。但我不想打破目前的客户。所以，我正在尝试使用版本控制实现一些REST API。因此，每当我更新端点时，消费者应用程序都不会崩溃。但我对如何进行API版本控制感到困惑。我想到了两种方式。
在同一服务器中创建下一个版本端点（在春季使用RequestMaping（“/ v1 / api1”），RequestMaping（“/ v2 / api1”）就像这样。）
其他明智地在新服务器实例中完全运行v2 API但保持相同的API端点占用空间并使用AWS APIGateway作为代理并在那里配置版本控制，然后根据版本号路由到旧服务器和新服务器在请求中。
但是我认为第一种方法会导致大量代码重复和代码管理混乱。因为我们在变体中保持相同的功能。
在第二种方法中，如果版本增加，我必须为机器人版本保留两组实例然后很难管理这些实例，特别是当我将拥有大约15个微服务实例时。它也不具有成本效益。因为我的公司是初创公司，所以我也需要考虑这个事实。
是否有关于API版本控制和管理多个端点版本的最佳做法？我愿意接受任何建议和指导。如果多个服务器也是解决方案，我愿意重新考虑成本限制。我需要这个问题的最佳解决方案。
答案 0 :(得分：1)
第一个问题是为什么需要新版本？ 您的合同是否已更改或内部逻辑是否有一些更改，以及您是否确实需要公开新版本。下一个要问的问题是你需要多长时间来支持旧版本以及你打算拥有多少个版本。 对于成熟的api，您可以使用方法2，尽可能减小占地面积。对于其他人，您可能会更好地通过相同的服务公开v2并解决它。 代码复制是一个因素，但取决于您更改的内容。如果所有关于合同的变更，你可以尝试使用相同的商业逻辑，并使其与新旧合同一起使用。
以下是一些您可能会觉得有用的链接