Difference between revisions of "OpenStackRESTAPI"
| Line 16: | Line 16: | ||
# 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 | ||
| + | == From Scope/Project thread perspective (Jorge W) == | ||
| + | === [[OpenStack]] REST API === | ||
| + | # 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 === | ||
| + | # 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 == | == Design Notes == | ||
# Should be a superset of Rackspace APIs | # Should be a superset of Rackspace APIs | ||
Revision as of 05:35, 5 January 2011
OpenStack REST API
Wiki Page for the blue print https://blueprints.launchpad.net/nova/+spec/open-stack-api
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 1. 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
- 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)
- 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
- 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
- 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
- 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
