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/