----- "Bryan Kearney" bkearney@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@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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
On 03/02/2010 03:37 PM, Justin Harris wrote:
----- "Bryan Kearney"bkearney@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@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?
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
candlepin@lists.fedorahosted.org