W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

RE: Issue 5; GET vs GetLastTradePrice

From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
Date: Thu, 2 Jan 2003 07:53:46 -0700
Message-ID: <9A4FC925410C024792B85198DF1E97E404A7C537@usmsg03.sagus.com>
To: www-ws-arch@w3.org

> -----Original Message-----
> From: Walden Mathews [mailto:waldenm@optonline.net]
> Sent: Thursday, January 02, 2003 9:25 AM
> To: Newcomer, Eric
> Cc: www-ws-arch@w3.org
> Subject: Re: Issue 5; GET vs GetLastTradePrice
> If I dereference a "service name" and get a body of 
> description on how to access that service, isn't
> that body still describing, at the end of the day, some 
> syntax and some semantics?  

Sure.  SOAP and WSDL aren't solving the world's problems, they are basically
just removing some of the mechanical impediments to describing and invoking
object interfaces across platforms, languages, vendors, etc. Just as the
hypertext Web generally works because there is an intelligent human reading
the rendered HTML, SOAP and WSDL work because there are intelligent humans
doing the mapping from the syntax level they describe to the semantics of
the underlying code.

> Isn't the need for "custom coding" a function of custom 
> interfaces, not the lack  of descriptive
> material about custom interfaces? 

I'm not sure what you're getting at, FWIW.  The big advantage of WSDL, IMHO,
is that it allows the generation of the code to generate the SOAP messages
and programming language classes to handle them.  That's clearly the selling
point for  something like the Google web service, which is much more complex
under the covers than a simple GET invocation of a URI with a query encoded
in it, but is simpler in practice for the legions of VisualStudio.NET (etc.)
programmers who can auto-generate a class that queries Google.  

If there is one example that I wish the REST advocates here would study
carefully, it's Google -- for better or worse (and I personally think for
worse!) the world was lured into reliance on a fragile, suboptimal, overly
complex interface simply because the code is generated "by magic" from a
WSDL description.  There's no reason that some future version of WSDL that
supports SOAP 1.2 couldn't allow us the best of both worlds -- the
robustness of a RESTful interface and the convenience of push-button code
generation. As I said in my last message in this thread, it's the TOOL
VENDORS, not the WSA, RESTifarians have to convince to support this stuff.
Received on Thursday, 2 January 2003 09:54:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:01 UTC