W3C home > Mailing lists > Public > www-ws-arch@w3.org > November 2002

Re: Roy's ApacheCon presentation

From: Mark Baker <distobj@acm.org>
Date: Wed, 20 Nov 2002 21:11:56 -0500
To: Anne Thomas Manes <anne@manes.net>
Cc: www-ws-arch@w3.org
Message-ID: <20021120211156.O21537@www.markbaker.ca>

On Wed, Nov 20, 2002 at 03:46:04PM -0500, Anne Thomas Manes wrote:
> Mark Baker said:
> >
> > You snipped out the HTTP/WSDL bit.  Do you agree that HTTP defines an
> > interface in the same way that a WSDL document does?
> No, I don't agree. The HTTP interface represents almost no semantic meaning.
> A WSDL interface can represent enormous semantic meaning. See Ugo's last
> message regarding the law of conservation regarding application semantics.

It's exactly the opposite.  A WSDL document declaring an operation
called "foobar" doesn't tell you what foobar means.  RFC 2616 tells you
exactly what "GET" means.

> HTTP has no knowledge of the contents of messages. SOAP/WSDL has extensive
> knowledge of the contents of messages. Therefore with SOAP/WSDL I can
> generate code to process my messages. I don't have to write all the code by
> hand.
> In many circumstances, I prefer to put some semantics into my interface
> because it makes the application development process that much easier.
> That's not to say that I don't like the REST approach, but I haven't seen an
> argument that works for me as to why it's so much better than the "abuse of
> POST" approach. I understand that REST takes better advantage of the power
> of the Web, and you can do things like create book marks and pass links, and
> cache results, etc. And these might be very desirable features in some
> circumstances. But from my perspective, most "real" Web services (filing my
> taxes online, submitting an insurance claim, ordering a thousand widgets,
> managing logistics, posting an email correspondence to my CRM system at
> Salesforce.com, etc.) will require SOAP headers for security, management,
> reliability, message coordination, etc. The REST approach can't address
> these requirements.

Of course it can.  S/MIME is a perfectly good security solution that
works with HTTP.  The RFC 822 Message-Id header can also be used with
HTTP.  Anything that can be done with a SOAP header can be done with an
HTTP header (except scoping and mandatory extensions, so just use PEP
or, in the future, Waka).

Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food
Received on Wednesday, 20 November 2002 21:08:21 UTC

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