Marc Hadley wrote:
> On Feb 19, 2008, at 5:08 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. And pass
in UriInfo to MessageReader and Writer as well. Would allow people to
write their own annotations and bindings.
Still, I think composition with Param annotations and JavaBeans is
something that is natural and should be in the spec.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com