Re: JSR311: JAX-RS Client API

From: Stefan Tilkov <>
Date: Fri, 12 Oct 2007 22:10:03 +0200

A client API would be nice, although I'm not sure the annotation-
driven approach makes as much sense as on the server side. But
unless I'm mistaken, anything we'd come up with would have to be
created in a hurry, and I don't believe there's a good enough chance
something very good would be the result.

My vote would be to stick to the original plan and postpone this to
another JSR.

Stefan Tilkov,
On Oct 12, 2007, at 5:08 PM, Patrick Mueller wrote:
> On Oct 12, 2007, at 9:59 AM, Marc Hadley wrote:
>> ... However I'm concerned that the kind of approach you suggest  
>> with annotated interfaces would really result in hiding the  
>> uniform interface behind an RPCish facade and I don't think that  
>> is what I'd want in a RESTful client API.
> Good point.  Especially the "I don't think that is what I'd want ...".
> Since no-one is looking at the client space, all we can do is  
> imagine.  The status quo on the client seems to be ... use raw HTTP  
> libraries.  I think we can abstract some of that ugliness away.  Of  
> course, careful to still allow low-level tweaking at the HTTP  
> level, when you need it.
> 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.
> 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: