HATEOAS Patch

Devan Goodwin dgoodwin at rm-rf.ca
Wed Aug 18 12:57:05 UTC 2010


Attached is a work in progress patch for HATEOAS support.

In terms of what it does, I think it's exactly what we want. We have
one custom serializer which we register for all our linkable types.
This serializer can check the context it's in. If serializing a root
object, we want to just proceed with normal serialization. (more on
this later) If serializing within another object, we want to manually
output our JSON with just an 'href'. Not added yet but we'll do
exactly the same if within a collection, and there is a context for
this as well.

As far as making it happen it got a little messy. I had to dig way
into Jackson internals and the end result was creation of our own
SerializerProvider and SerializerFactory sub-classes. These are both
configured on the ObjectMapper, and then once in the serializer it
assumes the provider configured is our's and casts it. (if you tried
to use our custom serializer in an object mapper that didn't use our
serializer provider and factory, this would error out fast, but not a
problem generally as far as I've seen) Worst of all, there is a 30-odd
line method copied in our SerializerFactory that comes straight from
it's grandparent class in Jackson.

All of the above is done so we can register customer serializer, and
then within that serializer, have a method call available to us which
circumvents the custom serializers registered and just moves on to use
the default. (thus preventing infinite recursion with our serializer)
I tried everything I could come up with to manually create the default
object serializer but it's a BeanSerailizer in Jackson and it's
creation is non-trivial.

So while this code doesn't thrill me, it's isolated and not something
that can spread throughout the code base, and the end result JSON
appears to be spot on for what we want. If in the future it were to
become unmaintainable or break, we could work out another solution, or
do custom serializers for all our objects, and just keep the JSON
consistent. As such I think it's worth proceeding with this, provided
there are no hidden gremlins.

Still to do:
- Possibly serialize ID along with href. (watch out for consumer.uuid
and soon, owner.key.)
- Linkify collections. (just need to check for context in CandlepinSerializer)
- Expand to more model classes. (certs, subscriptions, possibly a couple others)
- Add top level links to resources.
- Fix *everything*, cuke/rspec, RHSM, etc.

Still a bit of work to be done to finish it off, particularly in the
last step. This patch has been pushed to the hateros2 branch.

There is possibility here for a patch submission to Jackson I think.
This solution isn't it, but I think a new annotation that would
automagically do most of the above might be.

Cheers,

Devan

-- 
Devan Goodwin <dgoodwin at rm-rf.ca>
http://rm-rf.ca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-HATEOAS-support.patch
Type: application/octet-stream
Size: 19684 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/candlepin/attachments/20100818/af3b6abb/attachment.obj>


More information about the candlepin mailing list