Jump to: navigation, search

Difference between revisions of "OpenStackRESTAPI"

m (Text replace - "__NOTOC__" to "")
 
(3 intermediate revisions by one other user not shown)
Line 1: Line 1:
__NOTOC__
+
 
 
= [[OpenStack]] REST API =
 
= [[OpenStack]] REST API =
 
Wiki Page for the blue print https://blueprints.launchpad.net/nova/+spec/open-stack-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 ==
 
== Notes from e-mail chain ==
Line 12: Line 14:
 
# It is a lightweight framework and will have capabilities for service components to expose feature sets via declarative sets
 
# 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)
 
# 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
 
# It will be JSON/HTTP
 
# We should have appropriate media types for the [[OpenStack]] API services
 
# 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)
 
#* 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  
+
#* 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)
 
# 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
 
# A first client implementation could be a CLI for an [[OpenStack]] Cloud system
Line 25: Line 28:
 
# Projects may also expose notification interfaces.  These should also be based on HTTP/REST (Atom/PubSubHubBub).
 
# 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.
 
# 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) ===
 
=== Dev APIs (Internal or southbound APIs) ===
 
# Additionally, there may exist DevAPIs, these APIs are targeted exclusively to project developers
 
# Additionally, there may exist DevAPIs, these APIs are targeted exclusively to project developers
 
# DevAPIs help developers build [[OpenStack]] components
 
# 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.
 
# 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.  
+
# 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 ==
 
== Design Notes ==
 
# Should be a superset of Rackspace APIs
 
# 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
 
# Need higher levels abstractions for datacenter/Cloud System, composite application and so forth
 
# Storage and Network layer abstractions
 
# Storage and Network layer abstractions
  
 
Related Blueprint : https://blueprints.launchpad.net/nova/+spec/easy-api
 
Related Blueprint : https://blueprints.launchpad.net/nova/+spec/easy-api

Latest revision as of 23:29, 17 February 2013

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)
    1. Extensibility mechanism http://wiki.openstack.org/JorgeWilliams?action=AttachFile&do=get&target=Extensions.pdf
  7. It will be JSON/HTTP
  8. 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
  9. We could propose a first iteration at the next summit (April '11)
  10. 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)

  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
    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"
  2. Need higher levels abstractions for datacenter/Cloud System, composite application and so forth
  3. Storage and Network layer abstractions

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