Re: Web architecture

Hi Doug,

> Mark,
> 
> It seems you're raising a basic architectural point against SOAP

No, it's not an architectural point against SOAP.  I worked within the
XML Protocol WG to ensure that SOAP could be used in this manner.  The
key architectural issue is this one;

http://www.w3.org/2000/xp/Group/xmlp-issues#12

which resolved to my satisfaction, as it means that POST can be used
to mean POST.

SOAP 1.1 can also be used in this manner, whereas SOAP 1.0 cannot.

> while also
> invalidating most of the web services work (since before it got that name).

If it was a goal that this web services work build something that is
consistent with Web architecture, then that is true.

> SOAP and everything developed on top of it is providing a generic service
> (mostly packaging and transport infrastructure for SOAP itself) to higher
> layers in the application stack.  At the SOAP layer, it doesn't know whether
> the payload contained will create a purchase order, update one or delete
> one.  Higher layers don't know the transport SOAP will use and wouldn't know
> when to describe the appropriate HTTP action.  These software design
> efficiency arguments are somewhat specious and could be closed by saying
> "why not?" if they didn't remove dependencies between the application
> layers.  Onward...

Hey, if somebody wants to build a spec with SOAP that isn't Web
architecture friendly, nobody's forcing them.  I'm bringing this issue
up here because, if they want to suggest that we consider it, or if we
want to consider identifying it, we have to somehow deal with the part
of our charter that say "must cleanly integrate with Web architecture".

> Yes, HTTP POST is a wonderful transport for carrying XML and other payloads
> to and from your application.

With all due respect, no it isn't.

HTTP/POST is not a transport protocol.  Transport protocols mean "send
these bits here".  TCP is a transport protocol.  Transfer protocols, on
the other hand, assign meaning to the sending of those bits.  For
example, if I sent the HTTP message "3" with POST, it would mean
something different than if I sent it with PUT.

Also, GET is not for sending messages.  GET is for requesting that the
server send a representation of the resource identified by the
Request-URI.  e.g. a GET on http://www.markbaker.ca should return a
representation of me because I assert that http://www.markbaker.ca
identifies me.

> Even without that rant, what I fail to understand is why POST is
> inappropriate for outbound XML documents.  Most of the SOAP messages sent on
> the outbound HTTP hop (when using that binding) actually do cause changes at
> the receiving end, far beyond notations in the web server log.  They almost
> never create new addressable resources at the receiver.  This seems to be
> the essence of POST.

That's part of it, yes.  But not all of it.

>  While a few trivial cases could be handled through GET
> and a few parameters in the URL, trivial web services don't help the
> Business Infrastructure needs where ebXML Messaging and D-AG0017 sit.

POST *is* appropriate for "outbound XML documents", when those documents
are representations of resources, and when the sender wants the meaning
of POST to be used (as opposed to PUT).

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Friday, 15 March 2002 08:01:20 UTC