OpenStackRESTAPI

= 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.


 * 1) It will be used by cloud service consumers & operators to build higher level systems.
 * 2) It is REST-ful
 * 3) It will have a programming model appropriate for the audience and their use cases
 * 4) It will be version-ed
 * 5) It is a lightweight framework and will have capabilities for service components to expose feature sets via declarative sets
 * 6) 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)
 * 7) Extensibility mechanism http://wiki.openstack.org/JorgeWilliams?action=AttachFile&do=get&target=Extensions.pdf
 * 8) It will be JSON/HTTP
 * 9) We should have appropriate media types for the OpenStack API services
 * 10) * I have done it for CDMI, so have an idea how it could look like, if we decide to go this route)
 * 11) * 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
 * 12) We could propose a first iteration at the next summit (April '11)
 * 13) A first client implementation could be a CLI for an OpenStack Cloud system

OpenStack REST API (The northbound interfaces)

 * 1) Each core project will expose one or more HTTP/RESTful interfaces for the purpose interacting with the outside world.
 * 2) 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.
 * 3) Projects may also expose notification interfaces.  These should also be based on HTTP/REST (Atom/PubSubHubBub).
 * 4) 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)

 * 1) Additionally, there may exist DevAPIs, these APIs are targeted exclusively to project developers
 * 2) DevAPIs help developers build OpenStack components
 * 3) They need not be RESTful (though they can be), they might leverage other protocols, they may be python based, whatever.
 * 4) 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

 * 1) Should be a superset of Rackspace APIs
 * 2) 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"
 * 3) Need higher levels abstractions for datacenter/Cloud System, composite application and so forth
 * 4) Storage and Network layer abstractions

Related Blueprint : https://blueprints.launchpad.net/nova/+spec/easy-api