Jump to: navigation, search

Difference between revisions of "Governance/APIGuidelines"

(API Guidelines for Projects (DRAFT))
(Moved to Governance/Proposed/APIGuidelines)
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
== API Guidelines for Projects (DRAFT) ==
 
  
The intent of this page is to provide guidelines for OpenStack projects for the look and feel of their REST API interfaces
 
in order that we have a consistent look and feel across all the projects. Changing the APIs of older projects is a long
 
term process as need to retain backwards compatibility for users, but over time we can all slowly converge to a more
 
consistent API.
 
 
'''Note: This documentation is currently very much in development - an alpha version for discussion amongst those from the various projects who are interested in cross project API consistency. Feel free to add comments and guidelines you think we need to standardise on.'''
 
 
 
==== API Terminology ====
 
'''Common Issues'''
 
* '''tenant''' vs '''project'''
 
** We should always use '''project'''.
 
* '''instances''' vs '''servers'''
 
** We should always use '''servers'''.
 
 
==== Extensions ====
 
 
Use of API extensions is generally discouraged, though historically many projects have them. Where we have
 
extensions we should from the API client point of view have them look the same. If a project supports
 
extensions they should support the following features:
 
 
* Versioning
 
** All extensions should have client visible versioning to be able to signal changes to the API (both backwards compatible and backwards incompatible changes. Versioning may be of the form of versions on individual extensions or an api-wide microversion which allows clients to select a specific version of an API.
 
* Discoverability mechanism
 
** Ceilometer capabilities http://docs.openstack.org/developer/ceilometer/webapi/v2.html#capabilities
 
** Marconi use of home doc and JSON Schema https://wiki.openstack.org/wiki/Marconi/specs/api/v1.1#Get_Home_Document
 
* Extensions should be kept to a minimum. The core API should be reviewed regularly to incorporate features which were formerly extensions
 
** Too many extensions results in portability issues
 

Latest revision as of 10:24, 23 September 2014