NearlyDirectApi

Launchpad 入口: NovaSpec:nearly-direct-api
创建: 2011-02-18
贡献者: termie

总结

这是一个关于简单、通用、易于理解的 API 的提案，它紧密遵循底层实现，并为随着时间的推移扩展和维护它提供流程。

请完整阅读本文档，会有蛋糕的。

它基于已经为 Direct API（之前称为 "EasyApi"）完成的工作，并扩展了它，以提供一种在添加新功能时保持向后兼容性的机制。

特性

允许开发者在不更改 Nova 核心代码的情况下，向 Nova 添加额外的服务。
提供一个反射服务，用于列出可用的服务、方法及其扩展。
客户端库非常容易实现。
允许 Nova 快速开发，同时也易于维护向后兼容性。
易于修改和更新，以适应不断变化的需求和优化。
API 文档可以与常规文档一起自动生成。

具体目标

足够通用，可以支持各种部署模型，并提供基于 Rackspace 和 NASA 使用模型的具体示例。
在适用时，对其他接口持开放态度。
支持待定的身份验证和授权模型。

具体非目标

不要指导 Swift 的需求。

一些容易受此代码支持的未来路径

能够运行直接与各个进程关联的 API 端点（在无队列 RPC 系统中很有用）。
添加诸如速率限制、缓存、压缩以及对替代协议的支持等系统。

发布说明

在此版本中，我们添加了 OpenStack API 的新方向的第一个版本。我们将通过其自身的端点维护与现有 Rackspace API 的向后兼容性，并在新的端点上提供新功能。

新的 API 被设计得非常易于使用，其扩展机制将使我们能够以非常快的速度提供新功能，同时仍然能够通过未来的版本保持兼容性和稳定性。

随着此版本的发布，我们还发布了参考 API 客户端库，以帮助加快过渡到新的 API，以便新的客户端可以尽快利用新功能。

原理

API 就是 API

目前，我们实际上拥有定义单个服务（如 Compute 或 Volume）API 的类，而所有基于 Direct API 之外的 API 实现都在对这些实现的输入和输出进行大量的转换。

通过系统设计的功能最好地表达了 OpenStack 的全部功能，而不是通过为不同的系统设计的 API 并将其分层到其之上。

我们仍然保留限制暴露给公共（或任何其他端点）的方法的能力，以及提供专门支持与所有已发布版本向后兼容的端点的能力。

遵循 Pythonic 风格是好的

作为一个项目中，绝大多数是 Python，并且其当前的流行度和开发速度在很大程度上归功于遵循 Python 通常遵循的开发原则，因此，这种“Pythonic”方法本身就具有价值。

向后兼容性（以及向前兼容性）是可能的

Python 的一个成功案例，以及与 Java 开发的心理模型的一个重大偏差，是围绕“鸭子类型”，即即使对于寻找不同接口的多个客户端，也能够在无需严格版本化的接口契约的情况下提供兼容接口的想法。

此实现和提案遵循宽松和严格之间的适度路线，为核心开发者提供了一个大致自由的市场，并为客户端开发者提供了一个可靠的目标，其中一些开发者可能也是同一 OpenStack 系统中其他项目的核心开发者。

通过采用一些简单的实践，可以避免绝大多数与兼容性相关的问题。

更简单的数据结构和代码路径更好

很久以前，一位著名的程序员写道，拥有 100 个操作单个数据结构的功能，比拥有 10 个操作 10 个数据结构的功能更好。该陈述的部分真相在于，当基于简单的数据结构和概念构建系统时，潜在的涌现结构和有机适应性。

此实现和提案提供了一个非常、非常简单的接口，只需要了解一种操作风格和一种数据类型。

用户故事

前提条件

所有必需的 API 调用都可以通过此系统建模。
客户端可以轻松解析 JSON。

设计

实现

UI 变更

代码变更

迁移

测试/演示计划

未解决的问题

BoF 议程和讨论

使用本节记录 BoF 期间的笔记；如果将其保留在批准的规范中，请用于总结讨论内容并记录任何被拒绝的选项。