> 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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
