【发布时间】：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中定义版本，即保持向后兼容
标签： spring rest microservices aws-api-gateway api-versioning