OK.. Candlepin is not HATEOAS (http://www.infoq.com/articles/rest-introduction.. see the linking discusssion). Why/Why not..... discuss.
-- bk
On Mon, Mar 1, 2010 at 11:27 AM, Bryan Kearney bkearney@redhat.com wrote:
OK.. Candlepin is not HATEOAS (http://www.infoq.com/articles/rest-introduction.. see the linking discusssion). Why/Why not..... discuss.
Cuz I'm a n00b at REST?
jesus
On 03/01/2010 12:27 PM, Bryan Kearney wrote:
OK.. Candlepin is not HATEOAS (http://www.infoq.com/articles/rest-introduction.. see the linking discusssion). Why/Why not..... discuss.
-- bk _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
believe it or not i thought of that a few weeks back. i'm not completely sold that providing links to individual entities is the *only* way to go. otoh, http 1.1 (& the ability to keep http connection open in particular) will alleviate some of the performance issues.
having said that, if we want to have a truly generic set of api (that can serve any client), we may want to consider returning uri's instead of actual data in our queries.
another thing that caught my attention in the article is the use of queries: http://example.com/products?color=green
the way i'm currently interpreting this is: if you want to query your data using a non-unique identifier, you can do that by passing parameters on the url. i think i like that!
-d
On 03/01/2010 11:56 AM, Dmitri Dolguikh wrote:
On 03/01/2010 12:27 PM, Bryan Kearney wrote:
OK.. Candlepin is not HATEOAS (http://www.infoq.com/articles/rest-introduction.. see the linking discusssion). Why/Why not..... discuss.
-- bk _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
believe it or not i thought of that a few weeks back. i'm not completely sold that providing links to individual entities is the *only* way to go. otoh, http 1.1 (& the ability to keep http connection open in particular) will alleviate some of the performance issues.
having said that, if we want to have a truly generic set of api (that can serve any client), we may want to consider returning uri's instead of actual data in our queries.
another thing that caught my attention in the article is the use of queries: http://example.com/products?color=green
the way i'm currently interpreting this is: if you want to query your data using a non-unique identifier, you can do that by passing parameters on the url. i think i like that!
-d
For me.. this came out of the relationships. I Look at this
GET /entitlement/consumer/{dbid}/
and
GET /owner/{dbid}/entitlement : Get a list of entitlements for given owner
and I see the concept of entitlement as both an entity and a relatiohsip. So, I wonder if the first is rewritten as:
GET /entitlement {consumer_id = Foo}
and the latter returns
<entitlements> <entitlement ref="/entitement/{id"/>
-- bk
On 03/01/2010 01:37 PM, Bryan Kearney wrote:
On 03/01/2010 11:56 AM, Dmitri Dolguikh wrote:
On 03/01/2010 12:27 PM, Bryan Kearney wrote:
OK.. Candlepin is not HATEOAS (http://www.infoq.com/articles/rest-introduction.. see the linking discusssion). Why/Why not..... discuss.
-- bk _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
believe it or not i thought of that a few weeks back. i'm not completely sold that providing links to individual entities is the *only* way to go. otoh, http 1.1 (& the ability to keep http connection open in particular) will alleviate some of the performance issues.
having said that, if we want to have a truly generic set of api (that can serve any client), we may want to consider returning uri's instead of actual data in our queries.
another thing that caught my attention in the article is the use of queries: http://example.com/products?color=green
the way i'm currently interpreting this is: if you want to query your data using a non-unique identifier, you can do that by passing parameters on the url. i think i like that!
-d
For me.. this came out of the relationships. I Look at this
GET /entitlement/consumer/{dbid}/
and
GET /owner/{dbid}/entitlement : Get a list of entitlements for given owner
and I see the concept of entitlement as both an entity and a relatiohsip. So, I wonder if the first is rewritten as:
GET /entitlement {consumer_id = Foo}
and the latter returns
<entitlements> <entitlement ref="/entitement/{id"/>
-- bk _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
i certainly see the point in returning the list of uri's. i shall think about the former. -d
On 03/01/2010 12:44 PM, Dmitri Dolguikh wrote:
On 03/01/2010 01:37 PM, Bryan Kearney wrote:
On 03/01/2010 11:56 AM, Dmitri Dolguikh wrote:
On 03/01/2010 12:27 PM, Bryan Kearney wrote:
i certainly see the point in returning the list of uri's. i shall think about the former.
I am roping in some of the deltacloud guys to the discussion.
-- bk
candlepin@lists.fedorahosted.org
-
Bryan Kearney -
Dmitri Dolguikh -
Jesus M. Rodriguez