Re: Representation<T> and Entity<T>

From: Dhanji R. Prasanna <>
Date: Wed, 11 Apr 2007 22:32:17 +1000

On 4/11/07, Jerome Louvel <> wrote:
> Ok, I think I've agreed 10 times now :) to the need of a wrapper
> Representation<T> as long as it is not the default or recommended way to
> expose representations. For other cases, it is definitely useful.

glad to hear it =)

However, I would reiterate my objection to Entity<T>. While
Representation<T> is a utility wrapper for returned metadata in certain
cases, I hardly see why we need this for consumed entities when we can
declare additional annotated method parameters to take whatever combination
or granularity of metadata is available. There isn't a special case that it
serves (unlike Representation<T>).

I was only talking about the HTTP "Location" header but got confused with
> the "Content-Location" one which is different but also useful I agree.
> This
> actually reinforces my point that "RedirectRef" is a better than name than
> "Location". We can however keep the "Location" property on the
> Representation<T> class which is equivalent to the concept of "Content"
> (and
> Entity) in HTTP.

Why not have both on the Representation<T> interface?
getContentLocation() and getRedirectLocation().

Btw, does a "Location" header really make sense with returned content?

From RFC 2616
"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."

This seems to indicate that the response content is to be ignored, which
makes me wonder if Representation<T> is the correct artifact to be
supporting "Location." Just wondering...