Nova/ApiSerializationSpec

• Launchpad 条目：NovaSpec:nova-api-serialization
• 创建时间：2011年4月4日
• 贡献者：Mark Washenberger

总结

Nova 当前的序列化和反序列化方法限制了开发者修改请求和响应的能力。本规范提出了一种新的方法，将使处理序列化和反序列化问题时的开发更加容易。

发布说明

与本规范相关的更改不应直接影响最终用户。但是，它应该能够解决 Openstack API 中 XML 处理方面的不足。

原理

在 Nova 的当前实现中，Openstack API 中的所有控制器都依赖于单一的序列化/反序列化实现。在大多数情况下，所有的序列化逻辑都包含在这个单一的实现中。这种集中化导致了在 Cactus 开发推进过程中遇到的几个问题。

Adding XML namespace to the Openstack API::

 

在 Openstack API 的响应对象中添加 xmlns 属性需要修改项目级别的逻辑。

Differences in XML conventions::

 

有多种方法可以在 XML 中编码字典和列表。其中几种约定在 Openstack API 的各个地方都有使用。当前的实现仅支持一种类型，并且修改它以支持另一种约定在一种资源中是复杂的，并有引入无关资源的错误的风险。

JSON changes::

 

当前的 JSON 序列化实现是与 python 字典之间的直接转换。这意味着即使是对 API 规范的微小更改也需要更改控制器逻辑。

Extension attributes::

 

目前，向响应对象中注入属性的 Openstack API 扩展必须自行处理所有的序列化和反序列化。这可能会成为大量重复工作的一个来源。

Request validation::

 

所有的请求验证都留给控制器本身。这会使控制器代码混乱，并且是潜在的错误来源。

目标

当本规范实施后，开发者应该能够做到以下所有事情。

• 添加新的请求或响应，具有任意序列化和反序列化的形式，而无需编辑其他代码部分所依赖的现有序列化器。
• 编写最大程度的灵活的反序列化和控制器逻辑，而无需担心意外支持格式无效的请求。
• 定义现有响应对象的扩展属性，而无需重写该响应对象的序列化。
• 在适当的情况下重用序列化逻辑——而无需强制重用任何给定的序列化逻辑。

设计

待定

#!wiki comment/dotted
You can have subsections that better describe specific parts of the issue.

实现

待定

#!wiki comment/dotted
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

=== Code Changes ===

Code changes should include an overview of what needs to change, and in some cases even the specific details.

=== Migration ===

Include:
 * data migration, if any
 * redirects from old URLs to new ones, if any
 * how users will be pointed to the new way of doing things, if necessary.

测试/演示计划

待定

#!wiki comment/dotted
This need not be added or completed until the specification is nearing beta.

未解决的问题

待定

#!wiki comment/dotted
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF 议程和讨论

待定

#!wiki comment/dotted
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

---