Hi Patrick,
This is indeed out of scope for this JSR which focuses on the mapping
between Domain POJOs and RESTful Resource POJOs by leveraging the
annotations mechanism. This mapping is by nature specific to the
server-side.
However, the JSR is not aimed to be used standalone but within a Web
container like a Servlet container or a Restlet container. If you rely
on the Restlet framework, you can directly leverage its API which is
able to fully work for both client-side and server-side code as you
suggest.
Best regards,
Jerome Louvel
http://www.restlet.org
2007/8/20, Patrick Mueller <pmuellr_at_muellerware.org>:
> I searched the list for thoughts on 'client interfaces' concerning
> this JSR, and didn't see anything. The spec currently lists 'client'
> support as a non-goal.
>
> That's a little worrying to me. Because it seems like 'client' side
> interfaces should somehow be able to flow from the server side
> definition, and if there's noone thinking about this, that might end
> up being a harder job than it otherwise would be, once this JSR is
> baked.
>
> For example, if the service interfaces were annotated / described on
> Java interfaces, instead of classes, you could easily imagine that
> the interface could be used on the client as well. For instance, via
> Proxy.
>
> Things get tricky when wanting to describe a stream on either end of
> the message; and figuring out how to make an invocation asynchronous
> and cancellable on the client side might impact the method signatures
> in various ways (constraining the types further; addinging some kind
> of context/handler parameter).
>
> It won't be simple. But it would be quite valuable.
>
> Before you say "but Java is primarily used on the server; there
> aren't that many clients that will need this", I'll point out (per my
> previous note) J2ME. Sure would be nice to have a simplish RESTy
> framework for my phone-based apps.
>
> But there's a bene even for the server. I certainly expect that as
> folks start building out more and more services, that they'll be
> cases where service implementations end up being clients to other
> service implementations. Which could then make use of a client
> facing API.
>
> Patrick Mueller
> http://muellerware.org/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
>