Re: whenToUseGet-7 Making SOAP Restful

Mark Baker writes:

>> But IMO, trying to build something HTTP-like on top of 
>> SOAP, which in turn will often be on top of HTTP, is 
>> quite impractical and unnecessary.

I think this is a reflection of the Web's failure, so far, to separate a 
generic REST layer, from its embodiment in a particular protocol (HTTP). 
My proposal does not set out to recreate HTTP...it attempts to map a part 
of REST into SOAP.  We might also want to also do DELETE, but I think SOAP 
does the right thing by providing a structured architecture for exploiting 
POST (not HTTP POST, POST in general). 

Guidance sought from the TAG:  it's obvious there is a desire among some 
correspondents to drill on the SOAP/REST issue.  It's not clear to me that 
the www-tag list is the right place to hash out the details (or that this 
necessarily is the right time.)  Should we move this discussion to 
distApp?  How should we manage the need to figure drill on the 
SOAP/REST-specific issues, while also keeping the Tag in the loop on the 
underlying SOAP/REST/is-the-web-rest-only/is-soap-a-broken-w3c-activity 
discussion?  Thanks.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Mark Baker <distobj@acm.org>
04/26/2002 08:51 AM

 
        To:     "Williams, Stuart" <skw@hplb.hpl.hp.com>
        cc:     noah_mendelsohn@us.ibm.com, www-tag@w3.org
        Subject:        Re: whenToUseGet-7 Making SOAP Restful


Hi Stuart,

On Fri, Apr 26, 2002 at 09:09:46AM +0100, Williams, Stuart wrote:
> Just a thought anyway... a 'null' SOAP request message as the 'trigger' 
to
> use HTTP GET rather than some other 'magical' incantation. What do you
> think? Others? Mark B?

Noah's example was a good one to help illustrate the different ways in
which one can think of using SOAP, especially as it relates to making
use of the semantics of application protocols.

But IMO, trying to build something HTTP-like on top of SOAP, which in
turn will often be on top of HTTP, is quite impractical and unnecessary.
It's true that HTTP's extensibility and processing models aren't as rich
as SOAP's, but also IMO, these small improvements are no where near
enough to justify the huge cost of deploying such a solution.

I think that if SOAP has a future on the Web (as opposed to on the
Internet), it will be with the chameleon use where both SOAP and HTTP
are used by developers at the same time (though an EDI-like use of SOAP
over POST is fine, it's a niche).  But I've yet to see a SOAP library
that supports such a use.

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, 26 April 2002 19:23:42 UTC