Marc,
I like your suggestion in keeping an implementation specific this. I like
Bill's proposal a lot, but if the EG feels this is adding bloat to the API,
I'm highly in favor of a means where an implementation could provide this
functionality in standard way.
However, from a usability perspective, I think Bill's proposal could be more
common than not. For starters, it does improve readability of code. As the
number of method parameters, the legibility of the method diminishes. I can
imagine more than few instance, specifically database driven applications
using Hibernate or JPA, where you may be required to access records via an
alternate key. Being able to group a collection of parameters into in single
bean goes a long way to improve readability.
Citing an example from my own experience, I developed a small contact
manager application using an early version of RESTEasy that worked with
Hibernate. The contact entity contained 28 fields, all of which needed to
searchable. As you might imagine, the method had 28 parameters each
annotated with an @QueryParam. Under the hood, this method used Hibernate's
Criteria API using an Example restriction. With Bill's proposal, it takes a
lot of the mess out of mapping the query parameters to an object as the API
would do that for you.
Honestly, I think this is more than an 80/20 case and folks who are
developing RESTful applications using JPA or Hibernate will have a great
appreciation for the feature. But again, this could become something like
Hibernate's Criteria API where it's the value-add of the specific
implementation.
Ryan-
On 2/19/08, Marc Hadley <Marc.Hadley_at_sun.com> 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.
>
> Marc.
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
>
--
Ryan J. McDonough
http://www.damnhandy.com