These are all great points. Jersey seems to expose both strong and weakly typed APIs with the strongly typed one (@QueryParam) being available for certain use cases, and for the rest the developer has to fall back to the weakly typed one (@UriInfo).
I wish there was an approach which had the flexibility of @UriInfo, in terms of resource matching, but provided the strong type conveyance that @QueryParam provides.
For example with @QueryParam the endpoint signature conveys the expected type information and allows you to leverage the framework for resource matching and parameter type casting. I like that. With @UriInfo, the expected type information is buried in the resource method as an implementation detail and you have to perform the casting etc.
What I probably would like is the ability to have the following work without generating the "producing media type conflict" error:
@GET
@Produces(MediaType.APPLICATION_JSON)
public Response getResource(@QueryParam("name") final String name) {...}
@GET
@Produces(MediaType.APPLICATION_JSON)
public Response getResource(@QueryParam("name") final String name, @QueryParam("badge") final int badgeNumber) {...}
This exposes the type intentions of the API in the resource signature and lets the framework act as the bridge to manage the impedance between the application and the protocol which I think is its proper concern here.
-Noah
On Aug 2, 2013, at 2:09 PM, Tatu Saloranta <tsaloranta_at_gmail.com> wrote:
> On Fri, Aug 2, 2013 at 3:58 AM, Cameron Jones <cmhjones_at_gmail.com> wrote:
> On Thu, Aug 1, 2013 at 7:16 PM, Tatu Saloranta <tsaloranta_at_gmail.com> wrote:
>
> I think it is rather that as per JAX-RS (and, I would argue, most all frameworks) routing by query parameter is something that should not be done. There are many practical reasons for this, including the fact that whereas path is hierarchic, and lends itself to relatively easy mapping, and state machines, query parameter set is an unordered bag of things. And operating on such dynamic, heterogenous data is difficult from otherwise static handler.
>
> So really it's better to leave that to either app developer, or to another framework/library/abstraction.
>
> That is my reading anyway: I am not involved in JAX-RS or Jersey development, so this is just my opinion.
>
> -+ Tatu +-
>
>
> There is an impedance mismatch between Java method signatures and URI signatures which results in non-linear mapping. Akin to ORM and RDBMS.
>
> The potential for extending the JAX-RS dispatch algorithm would need to be the production of a most-sensible specification 'convention' over a one-to-one correlation.
>
> I'm not sure how feasible it is to extend the JAX-RS\Jersey dispatching, but the programmatic manipulation of parameters is always there.
>
> Perhaps given the current focus on JAX-RS 2 and CDI\DI features, the time for this is best left for possible investigation for JAX-RS 3.
>
>
> That, or just leaving it out of scope. Sometimes the best thing frameworks and APIs can do is to create clear boundaries of what is in scope.
> Not so much because feature X might not be useful, but that cost of adding it (from complexity, lack of cohesiveness, intuitiviness etc) is relatively too high.
>
> I have noticed that there are many cases where developers test the limits for things seem "too dynamic" to be handled by what is essentially system based on static type definitions: system that takes full advantage of static nature of type definitions.
> Partly this is because client-side is often implemented using more dynamic scripting languages, and resulting models (for data types, URLs) reflects looser limits. But that makes it harder to map these things.
>
> If anything, I wish developers realized that it is perfectly acceptably to do iterative design, and not be too averse to changing type, endpoint definitions, to find good compromises to keep all parts simple to implement, maintain.
>
> -+ Tatu +-
>