On 4/11/07, Jerome Louvel <jerome.louvel_at_noelios.com> 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...
Dhanji