微服务的API是服务端和客户端之间的契约。我们只能在不破坏API契约的前提下独立地改进微服务，所以契约很重要。如果改变了契约，就会影响到客户端应用或API 网关。
API的定义依赖于所用协议。例如使用（诸如AMQP这类协议）消息时，API由消息类型组成。如果使用HTTP和REST风格的服务，API则由URL和请求以及JSON格式的响应组成。
然而，即便初始版本的契约已经考虑周全了，随着时间发展，服务的API也可能需要改变。如果发生了变化，尤其是被多个客户端应用调用的公共API，通常无法强制所有客户端升级到新的API契约。通常这需要增量部署服务的新版本，同时也要让老版本和新版本服务契约同时运行。因此，服务的版本策略很重要。
如果API的改动较小，例如添加了属性或参数，使用旧版API的客户端应该能切换过来，和新版服务协同工作。我们可以为必需的属性提供默认值，客户端将会忽略任何额外的属性。
但有时我们需要对服务API进行不兼容的大版本更新。因为不能强制客户端应用或服务立刻升级到新版，服务端必须支持老版本继续运行一段时间。如果使用基于HTTP的机制（如REST），一种方式是把API的版本号嵌入到URL或HTTP头部。然后可以决定是在一个服务里同时实现两个版本的API，或是部署不同的服务来各自处理一个版本的API。此时一种较好的方法是采用中介者模式（如MediatR库）将不同版本的实现用不同的处理器来处理。
最后，如果使用REST架构，Hypermedia是用来进行服务版本化和改进的最佳选择。
其他资源
Scott Hanselman. 轻松实现ASP.NET Core RESTful Web API版本管理
http://www.hanselman.com/blog/ASPNETCoreRESTfulWebAPIVersioningMadeEasy.aspx
RESTful Web API版本管理
https://docs.microsoft.com/azure/architecture/best-practices/api-design#versioning-a-restful-web-api