微服务 API 是服务与其客户端之间的协定。 仅当不中断微服务的 API 协定时，才能独立发展微服务，这就是为什么协定如此重要。 如果更改合同，它将影响客户端应用程序或 API 网关。
API 定义的性质取决于所使用的协议。 例如，如果使用消息传送（如 AMQP），API 将包含消息类型。 如果使用 HTTP 和 RESTful 服务，API 由 URL 和请求和响应 JSON 格式组成。
但是，即使对初始合同深思熟虑，服务 API 也需要随着时间的推移而更改。 发生这种情况时（尤其是当 API 是多个客户端应用程序使用的公共 API 时），通常不能强制所有客户端升级到新的 API 协定。 通常需要以同时运行旧版本和新版本的服务协定的方式增量部署服务的新版本。 因此，必须制定服务版本控制策略。
如果 API 改动较小，例如向 API 添加属性或参数，则使用较旧 API 的客户端应切换到服务的新版本。 你可能能够为所需的任何缺失属性提供默认值，并且客户端可能能够忽略任何额外的响应属性。
但是，有时需要对服务 API 进行重大和不兼容的更改。 由于可能无法强制客户端应用程序或服务立即升级到新版本，因此服务必须在一段时间内支持旧版 API。 如果使用基于 HTTP 的机制（例如 REST），一种方法是将 API 版本号嵌入 URL 或 HTTP 标头中。 然后，可以决定在同一服务实例中同时实现这两个版本的服务，或部署每个处理 API 版本的不同实例。 此功能的一种良好方法是使用 中介模式（例如 MediatR 库），以解耦不同实现版本并将其转换为独立的处理程序。
最后，如果使用 REST 体系结构， Hypermedia 是用于版本控制服务并允许可演变 API 的最佳解决方案。
其他资源
斯科特·汉塞尔曼 ASP.NET Core RESTful Web API 版本控制变得简单
https://www.hanselman.com/blog/ASPNETCoreRESTfulWebAPIVersioningMadeEasy.aspx对 RESTful Web API 进行版本控制
https://learn.microsoft.com/azure/architecture/best-practices/api-design#versioning-a-restful-web-api罗伊·菲尔德丁 版本控制、超媒体和 REST
https://www.infoq.com/articles/roy-fielding-on-versioning
