Following up on the url structure

Bryan Kearney bkearney at redhat.com
Tue Mar 2 19:28:44 UTC 2010


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}


Thouhgts? Am I off base on this?

The rules I am coming back to is this:

GET /RESOURCE is a collection of resources
GET /RESOURCE?{queryString} is a filtered collection of resources
GET /RESOURCE/{id} is a specific resource
GET /RESOURCE/{id}/SUBRESOURCE is a specific collection of child 
resources which could also be represented as /SUBRESOURCE?resource={id}

If we want to get nutty, then we could do

GET /RESOURCE/{id}/SUBRESOURCE/{sid} is a specific item from the child. 
Note, this can also be represented as GET /SUBRESOURCE/{sid}

GET /RESOURCE/{id}/SUBRESOURCE?{query_string} is a filtered collection 
of children. Note, this is the same as /SUBRESOURCE?{query_string} with 
an extra resorce={id}

-- bk



More information about the candlepin mailing list