Following up on the url structure

Bryan Kearney bkearney at redhat.com
Tue Mar 2 20:45:52 UTC 2010


On 03/02/2010 03:37 PM, Justin Harris wrote:
>
> ----- "Bryan Kearney"<bkearney at redhat.com>  wrote:
>
>> On 03/02/2010 09:54 AM, Dmitri Dolguikh wrote:
>>> On 03/02/2010 09:41 AM, Bryan Kearney wrote:
>>>> I checked in a quick model based on the discussions from yesterday.
>> I am
>>>> playing around with owners and pools since it is out of the way of
>> the
>>>> client code, and displays the pattern we have been chatting about.
>> If
>>>> you pull the latest you will see the following urls
>>>>
>>>> GET /owner/1/pool gives you all the pools for owner 1
>>>>
>>>> GET /pool gives you all the pools
>>>>
>>>> GET /pool?owner=1 gives you all the pools for owner 1
>>>>
>>>> GET /pool?product=SPACEWALK-001 gives you all the pools for the
>>>> specified product
>>>>
>>>> GET /pool?product=SPACEWALK-001?owner=1 gives you all the pools for
>> the
>>>> specified product and owner
>>>>
>>>> I like this pattern because it recoginizes that pools and owners
>> are
>>>> first class resources, and that there is a "Blessed" relationship
>> of
>>>> owners having pools. Everything else is a query parameter. Neither
>> of
>>>> these should support adding (since you dont add pools) but if they
>> did I
>>>> would assume there would be support for POST/PUT at both:
>>>>
>>>> /pool and /owner/{id}/pool
>>>>
>>>> Now.. if we move this pattern out to the rest of the API..I think
>> it
>>>> really only effects a few of the APIs. I think it would effect
>>>>
>>>> GET /entitlement/consumer/{dbid}/product/{dbid}
>>>> GET /entitlement/consumer/{dbid}/ :
>>>>
>>>> which would become
>>>>
>>>> GET /consumer/{dbid}/entitlement with some query parameters
>>>> or
>>>> GET /entitlment with some query parameters
>>>>
>>>> It would also effect the POSTS, which would be off of /entitlment
>> or
>>>> /consumer/entitlement
>>>>
>>>> Thoughts?
>>>>
>>>> -- bk
>>>> _______________________________________________
>>>> candlepin mailing list
>>>> candlepin at lists.fedorahosted.org
>>>> https://fedorahosted.org/mailman/listinfo/candlepin
>>>>
>>>
>>> i do like the differentiation between first class relations and the
>>> rest. I actually find it cleaner.
>>> -d
>>
>>
>> Continuing this thread.. I just pushed in support for
>>
>> GET /pool?consumer={consumer_uuid}
>>
>> which would replace (I think) the getEntitlementPools client API which
>>
>> is currently set to be
>>
>> GET /pool/consumer/{consumer_uuid}/
>>
>> which I think is a better fit.. since the client could do the
>> following
>> if they wanted:
>>
>> GET /pool?consumer={consumer_uuid}&product={product_id}
>
>
> What is the semantics of this?

This is basically saying "Give me all pools given a consumer Id and 
product id"

>
> My thought was that query parameters == filters for collections (such as /pools).
> So are these entitlement pools that are available to the given consumer?  This feels a little strange to me.
>
> perhaps the query would be through the consumer resource?
> GET /consumers/4/pools        - available entitlement pools for the consumer
> GET /consumers/4/entitlements - current entitlements for the consumer

This is the issue and the feature of this model. if we support both

/RESOURCE/{id}/SUBRESOURCE
and
/SUBRESOURCE?{query_stirng}

we will have 2 means of getting to the same data. I dont think this is 
bad. But, we may want to look at the notion of embedding the "preferred" 
url into each resource.

-- bk



More information about the candlepin mailing list