On 12/12/06, Steve Jones <[EMAIL PROTECTED]> wrote:
> Alex, PLEASE go an read more on WS-*, most people aren't using it as
> RPC _between_ endpoints, but are providing an "object" style interface
> onto the invocation sides of the exchange, thus hiding the complexity
> from the developer.
Glad you think I know so little of the WS-* stack. :) I use it every
day with a variety of systems, and seriously, RPC is mostly what these
interfaces provide. Sure you can wrap your API's into objects, no
problem, but they still amount to the principles of RPC; call a
function or method on an object with some parameters to invoke
business rules with data. And I hope you're not suggesting that OO
hides complexity better than good ol' procedures? :)
> You also _don't_ have to know "bucketloads" on how that state impacts
> things if the service has been well designed,
Well, "well designed" is a big cop out, as you can say that about anything. :)
> you need to know
> _enough_ to complete your interaction. REST also requires you to
> understand the impact of state change.
Actually, the dynamically REST system we've got only gives you
contextual endpoints, and as such does not require you to know about
state at all in a lot of cases. But I guess we can argue back and
forth about this, as we're on a strictly hypothetical level without
proper use cases. Yes, we as developers need to know shit, we need to
know what's going on, and what happens next, WS-* and REST the same.
I find it very hard to talk with you about these things. A lot of
these things are about design more than they are about wheter you
technically can do it. They both can do it, no problem. With REST
there are some principles in place that just simply wins me over, such
as ;
* Guaranteed GET for all resources (with content negotiation if you
want it; XHTML for browsers [or a Wiki page],
application/x-cool-invoice for your application, XML for debuggers
[browsers set up with it]) which makes it a doddle to see if I'm at
the right place at any given time. I don't need a fancy tool in an IDE
to do this; just a browser, or telnet, which makes it very easy to
capture the info, store it away, proxy it, forward it, document it,
and so forth.
* The resource orientation itself (I don't need to know how to invoke
the "object", only how to use it) which also makes you think in
different semantic terms than objects (more structure and taxonomical
relationships), which is compatible with how most people on the planet
uses URL's.
* URL's are free; they can be bookmarked (by browsers as well as
applications and tools), which helps in exposing your design (both
semantics and schematics) and hook people in (GET is easy; it somewhat
becomes part of your documentation)
* Optional : Control of API schematics ; dynamically driven
machine-readable API's. (For static lovers: downside is of course that
they're dynamic :)
* Based on technology that's been around for yonks, and is proven to a
large extent in terms of reliance and scalability, and the technology
specifically is much, much larger than service orientation alone (if
you're into WS-*, you're into service orientation; REST grapples with
much more than that) which means more people have expertize in various
aspects of it.
I think that's my main positives. And I feel the negatives are more on
people's preference to the dynamic nature of REST more than what you
technically can do with it (but with a bit of proxying and caching,
REST can be pretty static too). Maybe people don't like the
multi-channeled nature of REST (content negotiating, mime-types) or
the lack of strong typing (at least by default; you can push XML
Schema based stuff down your pipeline if you want, but it just ain't
standardized).
I think a lot of people struggle with the lack of strong typing as
being part of the "API" as such (or, the resource orientation), that
you have to glue a bit instead of having the stack deliver things back
to you in strong typed ways. But is this a technological limitation,
or just a personal preference?
Alex
--
"Ultimately, all things are known because you want to believe you know."
- Frank Herbert
__ http://shelter.nu/ __________________________________________________
