从 Openstack Kilo 版本开始，nova 项目引入了一套新的 api 机制 API Microversion，以实现在对现有 api 持续开发改进的同时，保持接口的向后兼容性。
概念
它的基本工作原理是用户在使用时必须明确指定调用的 api 版本，这使得同一个 api 在不同版本下可以表现出不同的功能特性并且互不影响，即使在同样的云环境同样的接口条件下，也可以同时照顾到不同用户的不同需求，大大增加了云平台的灵活性和包容性。
由来
作为一个开源项目，nova 的各个功能也都经历了从小到大，从简单到复杂的演进过程，而且很多时候由于设计上的重构和功能上的更新等等原因，修改后的接口和之前的接口很难做到相互兼容，nova api 大版本从 v1 到 v2 的变动就导致了 v1 代码的全面废弃，而新的需求还在不断出现，加上 api 既有的 extension 机制派生出的多层功能扩展，导致 api 的实现代码越来越庞大和臃肿。
随着功能的增加和项目的产品化不断扩大，大版本的切换和公共接口的频繁变动不管是对开发人员还是对已有用户来说都是一件不可接受的事情，一个新的满足社区协同开发的机制势在必行。
API Microversion 的小版本号机制很好的解决了上面的问题：
天然后向兼容
用户自主选择需要的功能
可以递进式地对 api 接口做功能演进
减少了重复代码和修改工作量
保持代码整洁减少了维护开销
使用
现在，很多 Openstack 的项目都已引入了小版本号，而它的使用也很简单，只需要在rest 请求头里加入下面参数，service_type 用来区分组件服务，version_string 区分版本：
| OpenStack-API-Version: [SERVICE_TYPE] [VERSION_STRING] |
例如：OpenStack-API-Version: identity 2.114
查询
用户可以访问服务根路径来获取支持的 api 版本列表：
GET { "versions": [ { "id": "v2.0", "links": [ { "href": "https://192.168.13.30:8774/v2/", "rel": "self" } ], "min_version": "", "status": "SUPPORTED", "updated": "2011-01-21T11:33:21Z", "version": "" }, { "id": "v2.1", "links": [ { "href": "https://192.168.13.30:8774/v2.1/", "rel": "self" } ], "min_version": "2.1", "status": "CURRENT", "updated": "2013-07-23T11:33:21Z", "version": "2.53" } ] } |
min_version：表示当前 api 接口支持的最小 microversion
version：支持的最大 microversion，为空时表示此接口不支持 microversion
status：显示 api 的受支持状态，包括 CURRENT（持续优化演进）、SUPPORTED（仅修复必要bug）、DEPRECATED（即将废弃）、EXPERIMENTAL（实验接口仍未开发完毕），如没有特殊需求都应该使用 CURRENT 接口来获得稳定的服务功能支持。
microversion 版本号与新加入功能的对应关系，用户可以查看各组件的 api 文档，在接口描述或参数里会指明适用的小版本号。
开发人员可以查看 contributor guide 里的 REST API Version History，或者直接查看项目代码 api 路径下 api_version_request.py 文件，来获取各个 microversion 的功能演进详细信息。
When do we need a new Microversion?
