- From: Mark Baker <distobj@acm.org>
- Date: Fri, 15 Mar 2002 08:05:52 -0500 (EST)
- To: db134722@iPlanet.com (Doug Bunting)
- Cc: www-ws-arch@w3.org
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