[openstack-dev] Remove tenant/project ID from Nova v3 API URLs

Flavio Percoco flavio at redhat.com
Thu May 9 12:11:33 UTC 2013


On 08/05/13 18:01 -0400, Russell Bryant wrote:
>On 05/08/2013 05:27 PM, Gabriel Hurley wrote:
>> Proposal: The project/tenant ID should be dropped from the Nova v3 API URL structure.
>>
>> Rationale: Removing it would simplify the requirements on the Keystone Service Catalog, it makes the future path for clients/consumers doing API version discovery better, and it makes the URLs significantly shorter, cleaner and more human-parseable.
>>
>> The arguments in favor of including the project ID thus far have been twofold, both of which I will thusly invalidate:
>>
>> 1. RESTfulness -- in purest REST the context of a request should not in any way alter the results returned by that endpoint. Thereby the argument was that we have to include the project ID in the URL in order to ensure that the "context" doesn't change the results. However, the project ID has not been the defining factor for what is returned by the RESTful URL for some time. We're actually using the AUTH TOKEN context to vary the response, so the entire argument is already faulty. That aside, the argument in favor of including the project ID in the URL to be "proper" is built on a somewhat dated notion of RESTfulness which many implementers (even within OpenStack) have chosen to eschew. I don't believe we gain anything by trying to adhere to this standard on principle when it offers no benefit.
>>
>> 2. Caching -- a completely naïve cache would rely solely on the URL path to cache responses. As described above, this is already broken because two users with different roles may receive different responses on the same project ID. Any reasonable caching layer can cache based on a header, in this case Vary: X-Auth-Token.
>>
>> If anyone has other arguments in favor of keeping the project ID in the URL I'd love to hear them, but otherwise I formally request that it be removed going forward.
>>
>> All the best,
>
>This all sounds reasonable to me.
>
>If everyone agrees, we need a blueprint for it and make it a pre-req for
>the top-level v3-api blueprint.  Then, we may need a volunteer to take
>this on to make sure it gets done in Havana.  I feel like cyoeh has a
>pretty full v3 API plate already.
>

Sounds like a plan! +1

Cheers,
FF

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



More information about the OpenStack-dev mailing list