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
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
As an aside, I think that the standard naming scheme is for collections to be plural, so:
/pools = collection of entitlement pools /pools/3 = a specific pool (3) that is in the collection of entitlement pools
and the same for entitlements, owners, etc.
----- "Dmitri Dolguikh" dmitri@redhat.com 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 _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
On 03/02/2010 10:29 AM, Justin Harris wrote:
As an aside, I think that the standard naming scheme is for collections to be plural, so:
/pools = collection of entitlement pools /pools/3 = a specific pool (3) that is in the collection of entitlement pools
and the same for entitlements, owners, etc.
Yeah.. I had a question about that on the backlog.
-- bk
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}
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@lists.fedorahosted.org