Paul,
> Because a developer has to create their own annotated class for such
> common cases, like you did, rather than *reuse* Representation<T>.
As I corrected in a later reply, I meant Entry instead of Entity. I was
suggesting to annotate the Entry POJO (the "T" class) directly and not
create a wrapper POJO. In the Representation<T> approach, you still need the
T class. So adding a couple of annotations on this class shouldn't make life
of developers more complex.
If we can go as far as getting rid of Representation and Entity in the JSR
API, without loosing feature or overly complicating the code, it will be a
sign a better design. The fewer artifacts/concepts we specify in the API,
the easier it will be to learn and the lighter the implementations will be.
In the context of a lower-level API (or an API not based on annotations),
then it totally makes sense to have a Representation class (and even a
parent Variant class). We do have one in the Restlet API, so I perfectly see
its value.
> > The Entry POJO class is
> > necessary in all cases. Maybe you want Entry to extends a base
> > Entity/Representation class?
>
> No need. Entity<T> and Representation<T> encapsulate the type to be
> parsed/serialized, with common meta-data of the request and response,
> respectively without requiring modification of that type.
But if the media type (and other metadata) can be annotated directly on "T"
or externally when "T" is returned or received, what is missing?
In any case, the usage of Representation<T> or Entity<T> does require the
user to make its Resource POJO dependent on the JSR API (beyond
annotations), which makes the transformation as Web Resource less
transparent, not simpler.
Maybe we should test those ideas on some concrete examples to see how well
they float? I'm willing to write a Restlet-based prototype illustrating the
pure annotation approach if that can help moving the debate forward.
Best regards,
Jerome