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