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.
- application/pkcs7-signature attachment: smime.p7s