On status codes and redirects:
Why can't we rely on WebApplicationException be used to issue
redirects and other "special" status codes? We could create a
RedirectException class that extends WebApplicationException that
developers can leverage.
-Ryan
On 4/10/07, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
> On Apr 10, 2007, at 12:03 PM, Jerome Louvel wrote:
> >
> >>> @Status
> >>> int getStatus();
> >>>
> >>> and
> >>>
> >>> @RedirectRef
> >>> URI getRedirection();
> >>>
> >>> If the first method/annotation isn't present, we could also
> >>> generated a 303
> >>> or 307 status. If the getRedirection() method returns null, then no
> >>> redirection reference should be set in the response.
> >>>
> >> That means a developer now has to model all the details of a HTTP
> >> response in their resource (POJO) classes.
> >
> > In most cases, those annotations won't be necessary as the default
> > status
> > will work fine and there won't be any redirection.
> >
> The same applies to use of Entity<T>, Representation<T> and Response.
> You only use them when you need them, the rest of the time you can
> work with POJOs. However when you do need them they bring together
> everything in one place and IMO are much more convenient and
> intuitive than sprinkling a set of annotated properties representing
> aspects of the request and response through the method signature and
> class.
>
> >> Earlier you had objected
> >> strongly to any need for the resource POJOs to be changed to use the
> >> API beyond adding a few annotations, this sort of approach requires
> >> many new methods and a detailed algorithm describing how a container
> >> generates a response based on the values returned by those methods.
> >> I'd worry that whatever we did we'd miss use cases and end up with
> >> something lacking in sufficient flexibility.
> >
> > There might be better ways to express this. We could express static
> > redirections simply using annotations, like for resource URIs. Also
> > the
> > custom status could be directly returned by post() methods:
> >
> > @Resource
> > public MyResource {
> > ...
> >
> > @Redirect("/target/{var}")
> > public @Status int post(InputStream data) {
> > ...
> > }
> > }
> >
> > I came up with these ideas pretty quickly.
>
> Understood, Paul and I have been working on the API for many months
> now and have already explored some of the paths being suggested. It
> takes a while to work through the implications of each design choice.
>
> BTW, in the above suggestion, how would the post method set the value
> of {var} ?
>
> > Maybe we should step back a
> > little and see how those rough edges should be best polished. Are some
> > questions I have in mind:
> >
> > - How would someone writing domain POJOs (with no knowledge of JSR
> > 311 API)
> > would express redirections and custom HTTP status?
> > - Would he even express them the way we think of them (HTTP centric)?
> > - How can we compensate for the lack of expression for
> > redirections and
> > custom status for existing POJOs that we want to expose as resources?
> >
> > Probably the final solution will be a mix on several design paths,
> > but I'm
> > sure it is worth exploring as many of them before committing to a
> > final
> > design.
> >
> Agree completely.
>
> >>> The user code annotated with JSR311 should have any direct
> >>> dependency on the parent container (whatever it is), it should be
> >>> necessary.
> >>> All the useful context info should be injected in the
> >> annotated POJOs
> >>> instead.
> >>>
> >> s/should/shouldn't (for the first two should in the above) - right ?
> >
> > Sorry, here is the decoded version :)
> >
> > "The user code annotated with JSR311 shouldn't have any direct
> > dependency on
> > the parent container (whatever it is), it shouldn't even be
> > necessary. All
> > the useful context info should be injected in the annotated POJOs
> > instead."
> >
> Super, we agree !
>
> >> I don't like ParentRef, its not a reference to a parent. A uri
> >> template doesn't have to have any template variables, it can just be
> >> static.
> >>
> >> I guess we could go for something like @Resource
> >> (id="someuritemplate") instead.
> >
> > Agreed. @Resource("someUriTemplate") would be even simpler, with
> > the option
> > to specify @Resource(id="someUriTemplate", otherParam="xxx") if
> > necessary.
> >
> Except, syntactically, if you have "otherParam" you *always* have to
> write @Resource(id="someuri"), you can't use the shortcut @Resource
> ("someUriTemplate") even if otherParam has a default value. Its not a
> big deal but worth bearing in mind.
>
> Marc.
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>
>