OpenStack REST 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)
1. 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

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.

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.

Should be a superset of Rackspace APIs
1. 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