Re: Issue 133, and permitting no body

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:

                        ...your headers here
                ...body missing

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

                        ...your headers here

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

        To:     Noah Mendelsohn/Cambridge/IBM@Lotus
        cc:, (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 

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.

Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.

Received on Friday, 1 February 2002 17:07:24 UTC