On Fri, Sep 4, 2009 at 8:00 AM, Andrew Ochsner<aochsner_at_cs.stanford.edu> wrote:
> On Fri, Sep 4, 2009 at 3:13 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> Ah thank you. Makes sense now. I <personally> don't have a need or desire
> for that. Agree that old habits die hard. It wasn't until I started
> working with the Jersey client that I finally "got" REST. The proxy
> approach feels too RPC. Which isn't to say it's bad or anything. It's just
> not REST. Why not use SOAP/JAX-WS then? If what you're looking for is tool
> support and/or statically generated clients, then I think SOAP style
> services are a better choice. If that's your focus, do you really care what
> goes over the wire?
I agree with this. Not that it's bad, just feels... not quite optimal;
you could use that, but why.
> And, also... agree that providing a library to clients ala Sun Cloud API is
> a great approach and is what we do today. Writing that library is at least
> as easy if not easier for our REST services using the Jersey Client API as
> it exists today... as opposed to our libraries that talk to SOAP services.
100% agree here too -- my experience from within walls of another big
ws/cloud company (no, not Google or MS :) ) suggests that:
(a) It's important not to ONLY provide client; underlying "raw"
interface is very important -- there's always someone somewhere who
doesn't like your client, and/or can write better one for their needs
(or sometimes, in general :) )
(b) It is ALSO nice to provide a client; not just sample, but usable
one. This for people who have better things to do than writing client
code
So I think Jersey serves well between these two points (can write
clients as either provider, or for users to write their own).
-+ Tatu +-