Re: Representation<T> and Entity<T>

From: Dhanji R. Prasanna <>
Date: Wed, 11 Apr 2007 23:11:07 +1000

On 4/11/07, Jerome Louvel <> wrote:
> > Why not have both on the Representation<T> interface?
> > getContentLocation() and getRedirectLocation().
> Because you can issue a redirection without returning an output
> representation.

Right, this is why I doubled back on my suggestion and was wondering if
Representation<T> is the correct artifact for getRedirectLocation().

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

What would the alternative be? A second wrapper? or a derivative of
Representation<T> (ugh)?

In the current api--it looks like this is done via the HttpResponse object,
added as a keyed string to the header map. Im not hot on this approach

In one of our web frameworks, we have an event handler on a page (which
handles hyperlink clicks for instance) that returns either the target page
(equivalent of content) or a client-side redirect (interpreted and executed
as response.sendRedirect(..) by the framework--i.e. the "location" header).
In this case, I use a transparent wrapper with a static utility:

public Object nextPage() {
    return NextPage; //standard case

public Object nextPage() {
     return"http://...."); //redirect case

The downsides here are the use of the static utility and the ugly (Object)
return type. But it is certainly superior to throwing an exception.