We are abstracting the server side code to a pretty high level while not
completely hiding REST principals. What's been suggested for the client
takes a very similar approach, if not the same. You can make similar
arguments for JPA over JDBC, or CMT vs. BMT, etc.. There are obviously times
where having low level access is necessary, but for the majority of case the
higher level abstraction can serve the business purpose just fine. And a
proper implementation can sometimes get the job done better than the lower
level approaches.
Having had to instruct junior developers to utilize the Commons HTTP client
to access remote HTTP services can be a nightmare. It's worse than seeing
the evil that is done with home-grown JDBC frameworks I've had witnessed at
various client sites. SwingX-WS api does the best job to date of being a
higher level HTTP abstraction but it's still not released yet and also not
quite what I am looking for.
Here's the thing, if I'm a Facebook or Flickr and I'm trying to ensure that
my users have a solid, easy to use client API for as many platform as
possible. The ideas that have been proposed here would make it very easy to
support Java. If all I'd have to do is write a few interfaces and annotate
them, why wouldn't I support Java? It would even be super easy to stub out
the service interfaces using WADL.
However, perhaps there's a middle ground that can be reached. It could be
that the dead on simple way to have a service client is to just use the
interface and the framework will implement the calls. A more advanced
approach would allow the developer to create their own implementation. The
client implementation would be annotated with some type of annotation which
identifies it as the client implementation.
Taking its a step further, we could take a page from Restlet and consider
something like Call. That of course is getting a bit more ambitious, but I
think there's a way we can deliver a client spec while not making people
feel like they are loosing control.
Ryan-
On 10/12/07, Patrick Mueller <pmuellr_at_yahoo.com> 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
> 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
>
>
--
Ryan J. McDonough
http://www.damnhandy.com