I've ended up doing without ActiveRecord's to_xml/to_json to (among other things) accomplish HATEOAS within Rails. Instead I'm using xml builder and a roughly equivalent json-from-ruby-hashes template system. The process is a bit ugly at times, but so far the results have been pretty promising. We've already had api changes break enough internal clients that people are pretty excited about that never being their problem again.

I could wish that Rails had a cleaner path and this regard, though. I've never understood the thought process behind Rails' serialization system. Why use MVC to deal with html and email but almost ditch it entirely for other document formats? Especially when we're dealing with something that could really benefit from embedded hyperlinks.

I realize I implied "every table or model", and I would always argue for composition the way you describe it.

But ... there are good reasons to decompose and expose these things in your API. While maybe not for Public consumption but certainly for Private.

It's my opinion that the way REST beats SOAP in the enterprise is that in almost all cases it's much quicker to build decomposed services. And then likewise composition of said services is also much easier.

You would just have to include the URL where the client should POST the vote to (like with <form src=... in HTML pages) and it would be perfectly RESTful, imho.

Of course, it would be better if there was a Standard Poll Format to avoid the proliferation of custom formats that reduce code reuse, but alas, I don't think there is.