Dhanji,
> 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>).
Agreed.
> Why not have both on the Representation<T> interface?
> getContentLocation() and getRedirectLocation().
Because you can issue a redirection without returning an output
representation.
> 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...
Even if I think redirects won't have output representation in most cases,
I'm not sure that the spec prevents that.
Best regards,
Jerome