OpenStackRESTAPI
Contents
OpenStack REST API
Wiki Page for the blue print https://blueprints.launchpad.net/nova/+spec/open-stack-api
Update Jan 5, 2011 : As per further e-mail conversations, this could be merged with https://blueprints.launchpad.net/nova/+spec/openstack-api-parity
Notes from e-mail chain
OpenStack API is the Management & Control Plane for a Cloud Infrastructure built using OpenStack components.
- It will be used by cloud service consumers & operators to build higher level systems.
- It is REST-ful
- It will have a programming model appropriate for the audience and their use cases
- It will be version-ed
- It is a lightweight framework and will have capabilities for service components to expose feature sets via declarative sets
- Hackability is important - with orthogonal extensibility and discovery mechanisms in the framework (I think we can have a simple capability object/mechanism with a set of declarative name-spaced enumerations)
- Extensibility mechanism http://wiki.openstack.org/JorgeWilliams?action=AttachFile&do=get&target=Extensions.pdf
- It will be JSON/HTTP
- We should have appropriate media types for the OpenStack API services
- I have done it for CDMI, so have an idea how it could look like, if we decide to go this route)
- Either a MIME for req and resp say Content-type : opstk-req, Content-type : opstk-resp or by function viz. Content-type : os-nova-req, Content-type : os-swift-req
- We could propose a first iteration at the next summit (April '11)
- A first client implementation could be a CLI for an OpenStack Cloud system
From Scope/Project thread perspective (Jorge W)
OpenStack REST API (The northbound interfaces)
- Each core project will expose one or more HTTP/RESTful interfaces for the purpose interacting with the outside world.
- These REST interfaces may be consumed by the public (Public API), or operators (Management API). Orchestration and higher level systems should also consume these APIs.
- Projects may also expose notification interfaces. These should also be based on HTTP/REST (Atom/PubSubHubBub).
- The REST APIs will have a minimum set of standards and capabilities -- they will all be versioned, they should all be extensible, and support rate limiting, etc, etc.
Dev APIs (Internal or southbound APIs)
- Additionally, there may exist DevAPIs, these APIs are targeted exclusively to project developers
- DevAPIs help developers build OpenStack components
- They need not be RESTful (though they can be), they might leverage other protocols, they may be python based, whatever.
- DevAPIs should not be exposed outside a project's boundary. For example, if nova needs to interact with swift, it should interact with swift via the OpenStack API, never the DevAPI, that's for swift devs only.
Design Notes
- Should be a superset of Rackspace APIs
- Rackspace APIs currently have the goal "Launch and control Cloud Servers™ programmatically using a RESTful API". This interface has a similar goal "Launch and control Cloud Systems programmatically using a RESTful API"
- Need higher levels abstractions for datacenter/Cloud System, composite application and so forth
- Storage and Network layer abstractions
Related Blueprint : https://blueprints.launchpad.net/nova/+spec/easy-api