Ok I'm leaving this be for now. What we have in the hateoas2 branch:
- Most of our core objects have an href. (might need to be added to a
couple more)
- Top level links are provided if you GET the root of the webapp.
- Object relationships will be serialized in HATEOAS form. (just "id"
and "href")
- Collections will be serialized in HATEOAS form. (I still worry about
performance hit but we'll see)
- Unit tests + rspec passing.
TODO before a merge:
- Update RHSM for new link changes, mostly around collections.
- Cucumber test fixes.
Maybe TODO:
- Stop assuming paths in Ruby and Python libraries.
- Nested collection URLs are not discoverable or even consistently
implemented. Bit of work here I suspect, and not entirely sure how to
solve.
- Add a lazily loaded proxy Product object so we could serialize the
pool.product relationship as a link. (same for Subscriptions)
Cheers,
Devan
On Mon, Aug 30, 2010 at 2:21 PM, Bryan Kearney <bkearney(a)redhat.com> wrote:
On 08/30/2010 01:15 PM, Devan Goodwin wrote:
>
> Having some troubles seeing HATEOAS through to it's proper completion,
> I really cannot see how to properly model nested resources so you
> discover the links to them, rather than assume them.
>
> A list of the nested resources our Ruby library currently deals with:
>
> /owners/id/users
> /owners/id/subscriptions
> /consumers/uuid/entitlements
> /consumers/uuid/certificates
> /consumers/uuid/certificates/serials
> /consumers/uuid/atom
> /products/id/content
> /products/id/certificates
> /entitlements/product/productid (used for regenerating entitlement certs)
>
>
> For starters, note that there remains a circular dependency problem
> with a lot of objects, such as consumer's entitlements. Ideally I
> would like serialization of a consumer to include the array of their
> entitlements (in HATEOAS id+href form). This is fine in this case, but
> not during something like an export, which cannot do HATEOAS
> serialization and needs to write the entire object. (I'm working on a
> solution for this using Jackson views but I'm not sure it will pan
> out)
>
> So how *would* I know where to look for a consumers entitlements? Am I
> correct in assuming that ideally, consumer serialization would somehow
> include a link to the entitlements collection itself? Needless to say
> this is going to be tricky and our serialization is getting more and
> more complicated, but it may be possible.
>
> i.e.
>
> GET /consumers/{uuid} -> {'entitlements' =>
> '/consumers/{uuid}/entitlements')
>
> GET /consumer/{uuid}/entitlements -> [{'id' => 1, 'href'
=>
> '/entitlements/{id}, ...]
>
> Any thoughts?
I was assuming the latter.. but I could go with either. To be honest, if we
get the href in each object and it's parent then I would be fine calling it
good for a first cut.
-- bk
--
Devan Goodwin <dgoodwin(a)rm-rf.ca>
http://rm-rf.ca