Quoting Walden Mathews <waldenm@...>:

> | | WSDL+SOAP is very attractive because of its ability to generate
> | | client stubs in many languages: Java,C++, etc.

It's being a vote for WSDL+SOAP is a reason to discuss it, and that discussion
may possibly go back into rest-explore rather than rest-discuss matters (*if*
we
should compete in creating proxy stubs as WSDL+SOAP can then that might be
quite a challenge).

WSDL hides the network though, its raison d'ętre is to hide the network. If we
believe that hiding the network is a Bad Thing (one of the arguments of *some*
people evangelising REST is that it doesn't hide it) then we have to conclude
that WSDL is a Bad Thing. The description of "very attractive" is quite apropos
therefore because hiding the network is very attractive; as are all
anti-patterns.

On the other hand, just because we shouldn't hide it, do we need to look at it
all the time? We don't want every piece of code that calls into a REST service
to be primarily dealing in networking details, do we? (And if we do, to what
extent - do I really want to know I received a 304 instead of a 200, or just
invisibly benefit from the inherent performance gain).

Of course, since using a REST service tends to be simpler than using a SOAP
service (in and of themselves, before we add differences in tool support to the
mix) there is less need for wrapping and hiding of the type WSDL uses.
As long as I can do some sort of HTTP with whatever I'm using to develop I can
quickly use a REST service - and build whatever degree of abstraction into this
that seems appropriate for the task in hand.

With the stock ticker that seems to be the "hello world" of web services I just
need to concatenate the stock symbol to the service URI and do a simple search
on the returned data. With a more complicated service I'd probably want to
remarshall into some sort of OOP or Generic+OOP equivalent - but then I might
very well want to re-wrap the model of a more RPC-style service to better match
how I use it anyway.

More complicated services gain the most from WSDL. But these services generally
still require a relatively large degree of orientation to start using. While
some are saying that this will be reduced or removed by a layer on top of WSDL
(and on top of that, and on top of that) in the meantime this is still very
important. If this part of the complexity grows faster than the part of the
complexity removed by WSDL then the overall comparison still favours REST over
SOAP+WSDL.

On balance REST+WSDL seems inferior to REST to me right now.

--
Jon Hanna
<http://www.hackcraft.net/>
"…it has been truly said that hackers have even more words for
equipment failures than Yiddish has for obnoxious people." - jargon.txt