Open Stack

> vNext seems an interesting idea, I thought the implementation way for Nova
>> a little. "API Route Discoverability" is a nice design, but a root "/" URL
>> will conflict on current "list versions" API.
>> Maybe there would be a workaround.
>>
>
> Completely agreed, Ken'ichi. The "root" URL that returns the JSON-Home doc
> in the vNext API is actually *after* the version in the URI, though...
>
> So, the JSON-Home doc would be returned from:
>
>  http://compute.example.com/vNext/
>
> Of course, replacing "vNext" with "v4" or "v42" or whatever the "next"
> major version of the API would be. The real root would still return the
> versions list as it exists today, with a 302 Multiple Choice.
>
>
JSON Home and your JSON versions document can exist on the same path. The
JSON Home response should be returned when the Accept header is
"application/json-home"[1], and the JSON document when the Accept header is
"application/json". Webob makes it easy to support qvalues[2] for the
accept header.

This is how Keystone works for Juno, if you request `/` with "Accept:
application/json-home", you get the JSON Home document with paths like
`v3/auth/tokens`. If you request `/v3` with "Accept:
application/json-home", you get the JSON Home document with the paths like
`/auth/tokens`. This way, if your auth endpoint is / or /v3 the client can
use the json-home document. # TODO(blk-u): Implement json-home in
keystoneclient.

[1] https://tools.ietf.org/html/draft-nottingham-json-home-03#section-2
[2] http://tools.ietf.org/html/rfc2616#section-3.9

- Brant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140924/3b179dd7/attachment.html>