Following up on the url structure

Dmitri Dolguikh dmitri at redhat.com
Tue Mar 2 14:54:22 UTC 2010


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



More information about the candlepin mailing list