RE: Representation<T> and Entity<T>

From: Jerome Louvel <>
Date: Wed, 11 Apr 2007 11:55:28 +0200


> > True, but the implementation of those use cases based on
> > *unmodifiable*
> > classes does seem unlikely.
> >
> I disagree, I could see Representation<File> or
> Representation<InputStream> being used in those cases.

For File we could transparently expose them as representations without a
need to explicitly wrap them or even annotate them. People should also be
free to use the Representation<File> wrapper if they prefer.

A Representation<InputStream> wrapper is also a useful case when metadata
varies dynamically.

> > @Context could be replaced by a more generic @HttpParam (@Param
> > would be
> > better IMO).
> More generic in what sense ? We did consider something like:
> @Param(type=HEADER|QUERY|MATRIX|URI, name="...")
> but in the end we went for separate annotations @UriParam("..."),
> @QueryParam("..."), @HeaderParam("..."), @MatrixParam("...") for
> mostly aesthetic reasons.

Now that I think about it, my real issue is with the @HeaderParam
annotation, because it exposes too low-level information. I agree that we
need to provide a way to access to headers for special cases, but I'm afraid
that the specific annotation will make this practice too "recommended".
Other ones are fine indeed.

So, I withdraw my suggestion, but want to keep the @Context annotation to
inject the Resource context into POJO local variables, as an alternative to
exposing lower-level artifacts such as Request/Responses. This is mostly a
simplification/abstraction that I'm proposing.

> > @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.

HTTP definition of the "Location" header:
"The Location response-header field is used to redirect the recipient to a
location other than the Request-URI for completion of the request or
identification of a new resource."

Note that they mention "to redirect", so @RedirectRef seems more explicit
and removes the ambiguity with the other "Content-Location" HTTP header.

Best regards,