RE: Representation<T> and Entity<T>

From: Jerome Louvel <>
Date: Wed, 11 Apr 2007 12:35:04 +0200


> Im with Marc -- the general case wrapper Representation<T> is
> a simpler construct than creating a custom wrapper and
> "selling" it to the jsr311 runtime as the entity.


> I really dont see a problem with lots of annotations. It is
> totally not on par with a class explosion. Annotations are
> simply a nice way to capture metadata and in that sense
> little different to static, prepopulated fields. I think you
> will find new frameworks and use cases encouraging broader
> applications of annotations than merely as placeholders for
> text values (cf. google-guice or Apache Tapestry). I would
> have no problem with an api that had 15-20 annotations if
> their purpose were clear and concise. It is definitely not on
> par with 15-20 abstract classes or interfaces (with
> annotations, there are no operation or data semantics to
> learn, they are not extensible and they have limited, well
> defined targets).

Agreed too.

> @Param(type=HEADER|QUERY|MATRIX|URI, name="...")
> but in the end we went for separate annotations
> @UriParam("..."),
> @QueryParam("..."), @HeaderParam("..."), @MatrixParam("...") for
> mostly aesthetic reasons.
> In the same vein, I prefer this approach. I dont see any
> major advantage to @Param(type=blah) over @BlahParam. In fact
> I think it's more confusing and not as concise for the
> reasons Paul raised earlier.

OK, I changed my mind.

> > @RedirectRef is strictly equivalent to "ContentLocation" and
> > @Location.
> >
> But the two are different, Location is used outside of
> redirects,
> e.g. with a 201 response. IMO it would be confusing to
> use some kind
> of Redirect annotation where you aren't actually redirecting.
> Agreed, the name should be more exemplar.

I still think that @RedirectRef would be less ambiguous. See me other reply
to Marc based on HTTP definition of the "Location" header.

Best regards,