Patrick,
I think we're on the same page in regards to the idea of a the need to
define a client API for JAX-RS. I do recall your prior posts to the group on
this subject and initially, I agreed with the EG's original position.
However, I now have some second thoughts on not including a client API in
the spec. As I mention in my blog post, we could easily leverage thing like
the EntityProvider implementations in a client as well as the server. We're
already more than half way there and I don't feel it'd be a major effort to
take this on.
With where the spec is now, if we build on the idea of being able to
annotate interfaces as resources we could define a really successful client.
This would also open the door for a very elegant means of accessing existing
services like Facebook, Flickr, etc. The potential of a JAX-RS client could
make working with these services fare more elegant than it is today. While
other APIs like Swing-WS are much more elegant than say using the Apache
HttpClient, a JAX-RS client could be leaps and bounds better. My concern is
that be leaving a client definition out of JAX-RS, it would be like leaving
things like @WebServiceRef out of the JAX-WS spec.
Ryan-
On 10/11/07, Patrick Mueller <pmuellr_at_yahoo.com> wrote:
>
> On Oct 11, 2007, at 9:58 AM, Ryan McDonough wrote:
>
> I know the idea of a client API was deemed out of scope for the initial
> JAX-RS spec. However, after reading Bill Burke's feedback on the draft, it
> maybe a good idea to start thinking about this some more. I wrote up a post
> on the subject taking Bill's ideas a bit further:
>
> http://www.damnhandy.com/2007/10/11/the-potential-of-a-jax-rs-client-api/
>
> When you think about it, it wouldn't be a big stretch to implement a
> client API using some of these ideas. Thoughts?
>
>
> Not sure if I had pointed out that defining the services via interfaces is
> the pathway to nirvana in terms of reusing the service definition (the
> interface) on the client and server. Don't think I had mentioned "would
> prefer service definitions be interfaces than classes" in my original blog
> post; an oversight. All the service-related stuff I've done in the last two
> years uses the pattern of defining a service as an interface. I consider
> this to be pretty much of a requirement.
>
> One of the current rocks I've been beating people about the head with
> recently is this: for all the great server technology we're making
> available, we really need to take the client into consideration; for the
> lifetime of a particular service, you have a small number of folks who
> implement and maintain the service implementation, and orders of magnitude
> more people who can potentially be clients of that service. And yet, very
> few people seem to take the client into account. Even more important for
> someone building a framework to allow someone to implement services easily.
> A simple, stand-alone service like del.icio.us, even flickr ... you can
> deal with the client issues in a one-off manner. If there's something the
> framework can do to help, it should.
>
> Patrick Mueller
> http://muellerware.org/
>
>
>
>
--
Ryan J. McDonough
http://www.damnhandy.com