[
Lists Home |
Date Index |
Thread Index
]
On Wed, 12 Mar 2003 00:12:35 +0000, Bill de hÓra <bill@dehora.net> wrote:
> Mike Champion wrote:
>
>> CGI/JSP/ASP stuff on the client side *conceptually* different than Web
>> services?
>
> A difficult question to answer without a definition of "Web Services".
> But I'll bite...
>
> What CGI stuff on the client side?
DUHH!!! I meant CGI/etc. stuff on the server side.
> CGI defines an interface between applications/scripts and websevers. It
> has nothing to do with the Web's client/server contract; that's defined
> already by HTTP/SMTP/FTP and so on.
Sorry, I just don't buy that. For GET (and PUT/DELETE in theory but not
widespread practice) HTTP defines a reasonable and useful contract. But
much of the real Web that really works is a bunch of arbitrary stuff POSTED
from HTML forms or whatever, and the "CGI" details are the interface that
matters if you are writing a form to work with existing back end code or
back end code to process a form. My point was that this interface is no
more late bound than a "Web service".
> The difference is that most (all?) successful Internet systems are keyed
> off protocols. As protocols they have semantics that make them distinct
> from the 'protocol neutral' architecture implied by SOAP/WSDL; something
> imvho needs to downgraded to 'transport neutral' in the long term - there
> ain't no getting away from protocols if we're serious about
> interoperating applications.
That is the REST dogma, and I buy it as far as the synergy between HTML
links and HTTP GET is concerned. GETing a "representation" from a URI is
clearly the proven way to reference information in a scalable manner. But I
still haven't seen a compelling analysis that real, sucessful Web sites
adhere to REST when it comes to HTML forms and HTTP POST, i.e. linking to
those back-end applications that do things in the real world as opposed to
moving representations around the Web. Which is why I pushed back on
Mark's assertion that all/most successful internet applications are late
bound; I just don't see the evidence in practice.
And as far as 'transport neutral' is concerned, I very strongly suspect
that many successful websites are forwarding that information collected
over HTTP (by GET, POST, or whatever) to backoffice systems that are linked
by all sorts of proprietary protocols that most of us have only the dimmest
awareness of. The whole point of SOAP for many such users is indeed to "get
away from the protocols" and just ship the data around without regard to
language, platform, or vendor, or the underlying protocol. That's what XML
is good for, and why the Web services people latched onto it. [much to the
annoyance of Mr. St. Laurent and Mr. Harold :-) ]
|
