Re: Following up on the url structure

[Bryan Kearney]

On 03/02/2010 03:37 PM, Justin Harris wrote:
> ----- "Bryan Kearney"  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
> > > > [e-mail]
> > > > 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