On Feb 19, 2008, at 5:45 PM, Bill Burke wrote:
>>>>>
>>>> Thinking aloud, an alternative might be to allow an unannotated
>>>> method parameter even for HTTP methods that don't have an entity
>>>> body. Then you could have a custom message body reader conjur up
>>>> the bean from whatever combination of request information is
>>>> appropriate. That would let you write:
>>>> @GET
>>>> public String get(CustomerPK pk) {
>>>> }
>>>> public class CustomerPK {
>>>> String first;
>>>> String last;
>>>> int ssn;
>>>> }
>>>> Not sure I like that, I think the current mapping from entity
>>>> body to parameter is quite natural and this might confuse that.
>>>
>>> I think that alternative should be allowed too. It really depends
>>> on whether you want to decouple your mappings or not. Providers
>>> decouple, annotations couple. Coupling isn't also a bad thing.
>>> You sould be aware of the distributed protocol. You can always
>>> delegate to business logic.
>>>
>> The nice thing about the above suggestion is that you can write an
>> annotation-aware provider so there'd be a portable way to create
>> the kind of binding support you are suggesting without our needing
>> to bake it into the API directly.
>
> If that's true, then you should rename them to MessageReader and
> MessageWriter and allow any number of non-annotated parameters.
Yes, I was thinking along the same lines.
> And pass in UriInfo to MessageReader and Writer as well. Would
> allow people to write their own annotations and bindings.
>
Yes, injection on providers is already required by the spec.
> Still, I think composition with Param annotations and JavaBeans is
> something that is natural and should be in the spec.
>
Understood.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.