Paul,
> I don't think i was very clear on how i was evaluating
> simplicity. I was
> not evaluating it from a tally of classes/annotations. I was
> evaluating
> simplicity by asking myself the following question: how does
> a developer
> return a permanent redirect response?
>
> Using your proposed approaches as i understand them from the
> emails i am assuming one would do one of the following:
>
> 1) Implement a HTTP annotated method that returns void and is
> annotated with RedirectionRef; or
In addition it should be possible to annotate the class directly in case all
the method should be redirected, like when a resource moves to another
place.
> 2) Implement a POST method that returns void with a Context parameter,
> or a via a Context field on the class, and call the method
> redirectPermanent on the Context parameter/field when finished
> processing the request; or
Right.
> 3) Annotate a method with RedirectionRef than returns the reference.
> Ensure that this works with the appropriate HTTP request that
> requires a redirect response.
This might be useful for POJOs that dynamically define redirections and
naturally expose them via a getter. Otherwise, 2) is possible.
> Which should the developer use and why? What are the consequences for
> choosing a particular option? What are the edge cases or
> traps that the developer can get caught up in?
In most case, the redirection will be static, or simply based on a URI
template. In the other cases where it isn't true, if the POJO already
exposes the redirection URI, then annotating this getter method will be the
most natural, otherwise 3) will be used.
> Using the TemporaryRedirect class there is one very basic way
> of doing it:
>
> 1) Implement a HTTP annotated method that returns an instance of
> TemporaryRedirect.
>
> The java documentation for TemporaryRedirect can be kept very
> simple and
> precise:
>
> "Return an instance of this class to respond to a request
> with a 307
> (Temporary Redirect) response that contains a Location
> header field."
>
> It is concise enough to fit in at the package-level summary
> documentation.
If we have one class of TemporaryRedirect, we also need one for all common
statuses for consistency purpose. It also requires the POJO method to change
its return type using an API specific class, which is more intrusive than
the solutions above.
Best regards,
Jerome