84e953ca75
Change project name in doc according to style rules in http://docs.openstack.org/contributor-guide/writing-style/openstack-components.html Closes-Bug: #1537808 Change-Id: I849b0ec34a1bfc01263f35a9ef0128100945867e Signed-off-by: Danny Al-Gaaf <danny.al-gaaf@bisect.de>
76 lines
3.3 KiB
ReStructuredText
76 lines
3.3 KiB
ReStructuredText
Experimental APIs
|
|
=================
|
|
|
|
Background
|
|
----------
|
|
|
|
Manila uses API microversions to allow natural evolution of its REST APIs
|
|
over time. But microversions alone cannot solve the question of how to
|
|
ship APIs that are experimental in nature, are expected to change at any
|
|
time, and could even be removed entirely without a typical deprecation
|
|
period.
|
|
|
|
In conjunction with microversions, manila has added a facility for marking
|
|
individual REST APIs as experimental. To call an experimental API, clients
|
|
must include a specific HTTP header, ``X-OpenStack-Manila-API-Experimental``,
|
|
with a value of ``True``. If a user calls an experimental API without
|
|
including the experimental header, the server would respond with ``HTTP/404``.
|
|
This forces the client to acknowledge the experimental status of the API and
|
|
prevents anyone from building an application around a manila feature without
|
|
realizing the feature could change significantly or even disappear.
|
|
|
|
On the other hand, if a request is made to a non-experimental manila API with
|
|
``X-OpenStack-Manila-API-Experimental: True``, the server would respond as if
|
|
the header had not been included. This is a convenience mechanism, as it
|
|
allows the client to specify both the requested API version as well as the
|
|
experimental header (if desired) in one place instead of having to set the
|
|
headers separately for each API call (although that would be fine, too).
|
|
|
|
When do I need to set an API experimental?
|
|
------------------------------------------
|
|
|
|
An API should be marked as experimental if any of the following is true:
|
|
|
|
- the API is not yet considered a stable, core API
|
|
|
|
- the API is expected to change in later releases
|
|
|
|
- the API could be removed altogether if a feature is redesigned
|
|
|
|
- the API controls a feature that could change or be removed
|
|
|
|
When do I need to remove the experimental annotation from an API?
|
|
-----------------------------------------------------------------
|
|
|
|
When the community is satisfied that an experimental feature and its APIs
|
|
have had sufficient time to gather and incorporate user feedback to consider
|
|
it stable, which could be one or more OpenStack release cycles, any relevant
|
|
APIs must be re-released with a microversion bump and without the experimental
|
|
flag. The maturation period can vary between features, but experimental is NOT
|
|
a stable state, and an experimental feature should not be left in that state
|
|
any longer than necessary.
|
|
|
|
Because experimental APIs have no conventional deprecation period, the manila
|
|
core team may optionally choose to remove any experimental versions of an API
|
|
at the same time that a microversioned stable version is added.
|
|
|
|
In Code
|
|
-------
|
|
|
|
The ``@api_version`` decorator defined in ``manila/api/openstack/wsgi.py``,
|
|
which is used for specifying API versions on top-level Controller methods,
|
|
also allows for tagging an API as experimental. For example:
|
|
|
|
In the controller class::
|
|
|
|
@wsgi.Controller.api_version("2.4", experimental=True)
|
|
def my_api_method(self, req, id):
|
|
....
|
|
|
|
This method would only be available if the caller had specified an
|
|
``X-OpenStack-Manila-API-Version`` of >= ``2.4``. and had also included
|
|
``X-OpenStack-Manila-API-Experimental: True``. If they had specified a
|
|
lower version (or not specified it and received a lower default version),
|
|
or if they had failed to include the experimental header, the server would
|
|
respond with ``HTTP/404``.
|