Following up on the url structure

Justin Harris jharris at redhat.com
Tue Mar 2 20:37:37 UTC 2010


----- "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?

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


> 
> 
> 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
> _______________________________________________
> candlepin mailing list
> candlepin at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin



More information about the candlepin mailing list