Some ideas for resources representations

Hi,

I've been unable to assemble URL, so I get back to something I needed to do. Currently, I'm still completely unsure about how serialization, versioning... would work correctly, and furthermore how everything would interact with what we have (hydrators...).

Based on that (http://nicksda.apotomo.de/2011/12/ruby-on-rest-introducing-the-representer-pattern/) I've made the concept of Representer too. A Representer would be an object that would say "let's add this property or this collection to the represenation" BUT a representer does not any output, it does not render anything. The representer also hold data about HOW an association should be rendered: either just identifiers, or embedded into the main resource, or sideload.

We would have a basic Representer that would add all properties and collection with an ID policy.

Then we have a concept of ResourceSerializer. The resource serializer has access to the representer, so that it knows WHAT to render, and the serializer renders. As you can see in the code, there is also a concept of adapter for Resource serializer. This would allow to quickly swap from one JS library to another, based on conventions (I've done the one for Ember, as an example).

The thing that drives me ocmpltely crazy is HOW should this interact with hydrators. It seems that this concept of representers do some part that could be done by hydrator, but from my understanding, representer will do output, and hydrator only the hydrate part.

This is really complicated, because if we want to support versioning, I think we should support it everywhere: input filter, representers, hydrators... I think this makes it a LOT complicated and without any help I will be unable to do that, so I'm thinking about simplifying ZfrRest and not supporting versioning nor HATEOAS currently... But those things have so much influence over the architecture that I don't really know what to do...

What do you think @Ocramius ?