Open Stack

yes, it makes sense... +1 for the idea.

I also would like to see how priority you guys think this is, I mean, 
seems to me that this is kind of wish list, although if we leave this to 
later steps on H, can be problematic to remove

On 05/09/2013 09:11 AM, Flavio Percoco wrote:
> 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
>