[Jersey] Re: Adding grammar to the resources

From: Tatu Saloranta <>
Date: Fri, 2 Aug 2013 11:09:54 -0700

On Fri, Aug 2, 2013 at 3:58 AM, Cameron Jones <> wrote:

> On Thu, Aug 1, 2013 at 7:16 PM, Tatu Saloranta <>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 +-