But to the extent that they are all "lame database serialization" layers, I'd have to say "well - ya". REST is kind of just that.
I think that what you're really trying to say is that implementations you have found don't do HATEOAS.
I'm designing the API for Poll Everywhere right now. Internally a multiple choice poll resource consists of several database tables and Rails models, but I simplified the externally facing JSON representation down to:
{
multiple_choice_poll: {
title: "Fav color?",
options: ["Red", "Blue", "Green"],
sms_enabled: true
}
}
I'd love to implement a full HATEOAS stack on Ruby/Rails; we'll see if I get around to it.
---
BTW In case anybody needs to Google HATEOAS (like I did): http://en.wikipedia.org/wiki/HATEOAS
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.
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.
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.