Open Stack

On 02/05/13 08:34 +0100, Mark McLoughlin wrote:
>Hi Garbiel
>
>On Thu, 2013-05-02 at 00:46 +0000, Gabriel Hurley wrote:
>> Based on input from several of the PTLs (and others), I'd like to
>> propose the following outline for how version discovery should be
>> handled across heterogeneous clouds:
>>
>> https://etherpad.openstack.org/api-version-discovery-proposal
>>
>> Further discussion is absolutely welcome, and I would like to propose
>> it as a topic for review by the Technical Committee at the next
>> meeting since it involves a significant cross-project standardization
>> effort.
>I'd like to see us introducing new API versions a lot less regularly,
>but still being able to add new capabilities (and optional capabilities)
>in a backwards compatible and client-queryable way.
>

Agree!

>Some options for doing that:
>  * We add a 'GET /capabilities' which returns a document describing
>    which features this endpoints support - a feature could be optional
>    because it was added in a new version or because not all
>    deployments would be configured with it enabled. This would allow
>    clients to be able to query for features, rather than having a
>    hard-coded understanding of which minor versions support which
>    features.


What would be the client's behavior when querying an optional
capability that hasn't been configured server-side?

I mean, if it raises 404, should the client ignore that error?

>  * We adopt a more HATEOAS model where a client basically never
>    constructs a URL - everything can be reached via links in the
>    hypertext we return. If an endpoint doesn't support a given
>    feature, it just never includes a link to that feature in the
>    hypertext.


We've been experimenting with this in Marconi for some features and it
has made our life easier in some ways. We're not using it for the
whole API but for accessing resources and listing resources.

I'm not sure whether this can be completely abstracted from the
client, since there will always be required some api-version specific
code. However, I think it is a good thing to experiment with.

Cheers,
FF

-- 
{ name: "Flavio Percoco",
   gpg: "87112EC1", 
   internal: "8261386",
   phone: "+390687502386",
   irc: ["fpercoco", "flaper87"]}