Difference between revisions of "OpenStackRESTAPI"
m (Text replace - "__NOTOC__" to "") |
|||
(6 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
− | + | ||
= [[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 7: | Line 9: | ||
# It will be used by cloud service consumers & operators to build higher level systems. | # It will be used by cloud service consumers & operators to build higher level systems. | ||
− | # It is REST-ful | + | # It is REST-ful |
+ | # It will have a programming model appropriate for the audience and their use cases | ||
# It will be version-ed | # It will be version-ed | ||
# 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) | ||
+ | #* 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 22: | 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
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