W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2002

Re: Issue 133, and permitting no body

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 1 Feb 2002 16:52:24 -0500
To: distobj@acm.org
Cc: xml-dist-app@w3.org, ylafon@w3.org (Yves Lafon)
Message-ID: <OF04397CED.8B1C273C-ON85256B53.007846B0@lotus.com>
Your suggestion is good HTTP, but not good SOAP, IMO.  I think we want an 
approach that makes good use of both.

In practice, SOAP bodies are used to convey the "main intent" of a 
message, with headers used for modifier functions and metadata. 
Implementations are optimized around this idiom, description languages are 
tailored for it etc.  In that sense, a SOAP message without a body is a 
SOAP message without a purpose.  What would make more sense, I think, 
might be to have a particular SOAP body entry with a defined semantic of 
"retreive the resource to which this message is sent.  Instead of an 
envelope that looks roughly like:

        <envelope>
                <header>
                        ...your headers here
                </header>
                ...body missing
        </envelope>

You would have one or more body entries intended to be used for retrieval 
operations:

        <envelope>
                <header>
                        ...your headers here
                </header>
                <body>
                        <resourceControl:retrieveResource 
xmlns:resourceControl="..."/>
                </body>
        </envelope>

This is good SOAP.  It will be understood and easily generated by a 
variety of SOAP tools, and there are any number of sensible ways to encode 
this envelope into a retreival URI.  As with anything of this sort, you 
would have to publish guidelines on the appropriate use of the binding: 
break the guidelines and you're likely to get a system that misuses HTTP 
and/or SOAP. 

So, I think you can get what you want by putting in legal SOAP bodies. 
This is just the skeleton of a design, and care would be needed to ensure 
that the resulting URI's represent good web practice in the cases for 
which the binding is intended.  I have strong reservations about SOAP 
messages with out bodies.

------------------------------------------------------------------
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>
02/01/2002 11:41 AM

 
        To:     Noah Mendelsohn/Cambridge/IBM@Lotus
        cc:     xml-dist-app@w3.org, ylafon@w3.org (Yves Lafon)
        Subject:        Re: Issue 133, and permitting no body


> A SOAP message without a body seems
> to me to be a SOAP message that doesn't do anything, but carries in its
> headers lots of modifiers that would have applied if you were doing
> anything.  Maybe I'm missing something, but that doesn't make sense to 
me.

GET does do something (retrieval).  It just does it without side-effect.

Suppose somebody defines a transaction-id SOAP header.  Wouldn't it be
a good idea to permit GET to be used within a transactional context?

Rich has defined a SOAP extension for authentication.  Why not use that
for GET too?

I believe the same goes for any header which makes sense on an idempotent,
side-effect free method.

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, 1 February 2002 17:07:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:06 GMT