HATEOAS Patch

Justin Harris jharris at redhat.com
Wed Aug 18 13:56:15 UTC 2010


----- "Devan Goodwin" <dgoodwin at rm-rf.ca> wrote:

> 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.

Maybe we established this a while back, but does this mean that JSON is our
only supported format?


> 
> 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
> 
> _______________________________________________
> candlepin mailing list
> candlepin at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin



More information about the candlepin mailing list