微版本¶

API v1.0 支持微版本：API 的小型、有文档记录的变更。用户可以使用微版本来发现其云中支持的最新 API 微版本。升级以支持更新微版本的云仍然支持所有旧微版本，以维护依赖于旧微版本的用户的向后兼容性。用户还可以通过微版本轻松发现新功能，从而受益于当前云的所有优势和改进。

您可以使用微版本解决多种情况

较旧的客户端与新的云

在使用旧客户端与较新的云通信之前，旧客户端可以检查微版本的最低版本，以验证云是否与旧 API 兼容。这可以防止旧客户端因向后不兼容的 API 变更而崩溃。

目前，微版本的最低版本是 1.0，它与旧版 v1 API 兼容。这意味着旧版 v1 API 用户无需担心他们的旧客户端软件会在云升级到新版本时损坏。云运营商无需担心将云升级到新版本会破坏任何使用旧客户端且不期望这些变更的用户。

云之间可用功能的发现

可以通过微版本发现新功能。用户客户端应首先检查服务器支持的微版本。只有在云支持时，新功能才会启用。这样，用户客户端就可以同时与部署了不同微版本的云进行工作。

版本发现¶

版本 API 将返回最低和最高微版本。客户端使用这些值来发现 API 支持的微版本。

对“/”的请求将获得所有端点的版本信息。响应如下所示

{
  "versions": [
      {
          "id": "v1.0",
          "links": [
              {
                  "href": "http://openstack.example.com/v1/",
                  "rel": "self"
              }
          ],
          "max_version": "1.1",
          "min_version": "1.0",
          "updated": "2021-02-10T00:00:00Z"
      }
  ]
}

“max_version”是最高微版本，“min_version”是最低微版本。客户端应指定介于（包括）最低和最高微版本之间的微版本才能访问端点。

客户端交互¶

客户端通过使用以下 HTTP 标头来指定他们想要的 API 的微版本

OpenStack-API-Version: key-manager 1.1

注意

有关语法的更多详细信息，请参阅微版本规范。

从概念上讲，这类似于“Accept”标头。从语义上讲，这意味着

如果未提供 OpenStack-API-Version（指定 key-manager），则表现为指定了最低支持的微版本。
如果提供了 OpenStack-API-Version，则以该微版本响应 API。如果超出支持的微版本范围，则返回 406 Not Acceptable。
OpenStack-API-Version 的值为 latest（特殊关键字），则表现为指定了最大值。

警告

latest 值主要用于集成测试，并且在客户端代码中依赖它会很危险，因为微版本不遵循语义化版本控制，因此不能保证向后兼容性。客户端应始终需要特定的微版本，但将其限制为它在当时理解的微版本范围。

这意味着，开箱即用，不了解微版本的旧客户端可以与支持微版本的 OpenStack 安装一起工作。

从微版本 1.1 开始，将两个额外的标头添加到响应中

OpenStack-API-Version: key-manager microversion_number
Vary: OpenStack-API-Version

微版本

微版本¶

版本发现¶

客户端交互¶

Barbican 21.0.0.0rc2.dev2

页面内容