Re: JSR311: JAX-RS Client API

From: Heiko Braun <>
Date: Fri, 12 Oct 2007 21:17:42 +0200

On Fri, 2007-10-12 at 11:08 -0400, Patrick Mueller wrote:
> On Oct 12, 2007, at 9:59 AM, Marc Hadley wrote:
> > hiding the uniform interface behind an RPCish facade

IMO, this doesn't change the concept of the 'restful' uniform interface.
It's an implementation detail useful to generate the client side stubs,
similar to what the JAX-WS service factory does.

> Look at this way: we're abstracting lots of stuff on the server-side
> of the equation here. Why? If you believe, like many, that low-
> level HTTP access is the "REST way", why do we even have JSR 311?
> Why not just servlet, or presumably something better than servlet?


> We think we're adding value.
> Why can't we do the same on the client? Especially when there will
> be many, many more people writing client-side code than server-side
> code.

Just think of the TCK we are need to provide. This will requires a lot
of client code to drive the test suite. Working with the low level JDK
API is painful and even more advanced API's like apache commons don't
really make it more productive.

IMO when people talk about REST and HTTP, they often get HTTP as a
networking protocol and a programming model wrong. When i start thinking
about REST use cases, I can clearly picture the resource side. That's
fairly easy.

But think about a client-resource relation as a 1:n relationship.
The resource does just serve one client, but a client has to deal with n
resources. What's returned to the client may be a representation or list
of URI's to proceed. However in a medium complex use case client's have
to interact with many resources, probably traversing many locations
before the use case completes.

What i cannot see at the moment is how this should become a pleasure to
use when the client side programming model is not addressed properly and
you are left with the low level HTTP details.

Maybe someone with a little more experience in building restful
applications can shed some light on this?

> Unfortunately, the use case for Java client-side code, compared to
> say JavaScript client-side code, is a bit lacking. I think that's
> the only reason to ignore the client - not enough use cases.

> Patrick Mueller
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail: