Re: whenToUseGet-7 Making SOAP Restful

Noah,

Some comments follow. Thanks for taking this thread in a
constructive direction! :)

Cheers,

Chris

noah_mendelsohn@us.ibm.com wrote:

> Stuart Williams writes:
> 
> 
>>> it occurred to me that simply 'overloading' 
>>>a null request-message (ie. a requesting 
>>>node that requests an exchange and presents 
>>>no outbound infoset from which to from the 
>>>entity body of an HTTP request) to use 
>>>HTTP GET would yield something of very similar
>>>spirit to your proposal.
>>>
> 
> I think you're proposing a simple HTTP GET, returning a SOAP envelope. 
> That's an OK thing to do, but at the responding node it's not SOAP; the 
> SOAP processing model doesn't apply, SOAP faults can't be generated, it 
> can't be relayed through a SOAP intermediary perhaps through another 
> underlying protocol.  It's essentially an HTTP pull, causing a one-way 
> SOAP message to be sent to the requestor.  Sensible, but different. 


Hmmm... the magical GET SOAP message you describe has no headers
and so what is there for the SOAP processing model to operate upon?

    1. Determine the set of roles in which the node is to act. The contents of the SOAP envelope, 
including any header blocks and the body, MAY be inspected in making such determination.
    2. Identify all header blocks targeted at the node that are mandatory.
    3. If one or more of the header blocks identified in the preceding step are not understood by 
the node then generate a single SOAP fault with a value of "env:MustUnderstand" for faultcode (see 
5.4.8 Must Understand Faults). If such a fault is generated, any further processing MUST NOT be 
done. Faults relating to the contents of the body MUST NOT be generated in this step.
    4. Process all header blocks targeted at the node and, in the case of an ultimate SOAP receiver, 
the SOAP body. A SOAP node MUST process all SOAP header blocks targeted at it. A SOAP node MAY 
choose to ignore the processing implied by non-mandatory SOAP header blocks targeted at it.
    5. In the case of a SOAP intermediary, and where the message is to be forwarded further along 
the message path, remove all SOAP header blocks targeted at the node, and possibly insert new SOAP 
header blocks.

What is there left on which to Fault?


> 
> My SOAP envelope is not magical (sorry for the cute phraseology).  It's a 
> legal and appropriate SOAP envelope that says exactly what it means:  GET 
> the resource.  The fact that it has a clean mapping to HTTP is 
> intentional, but not its only use.  It can appropriately be used in any 
> context where a RESTful GET is intended.  In principle (though I ruled it 
> out in the initial proposal), it can be extended to be used with other 
> SOAP headers, as long as we watch out for safety issues.  Most 
> importantly, it's a SOAP message useable with the usual request/response 
> message exchange pattern, and processed by the usual SOAP processing rules 
> at the responding node.


But not all use of SOAP is request/response, that's just one MEP of a universe
of possible MEPs. In fact, Part 1 says nothing about responses until you
get to the Binding Framework section which only talks about responses
in terms of MEPs that one might define. In that sense, SOAP is a *message*
protocol, not a *messaging* protocol and maybe that's where much of the
confusion lies.


> 
> That said, I have no problem with a (possibly) additional specification 
> calling for a simple HTTP GET of a SOAP message (interestingly, and this 
> is intentional, the results on the wire would be essentially 
> indistinguishable).  The difference comes in whether the responding node 


exactly, so what I guess I'm missing here is why make the distinction
when none really exists? If you send an HTTP GET to a SOAP endpoint
URI that uses the HTTP protocol and that endpoint only supported the
HTTP POST method, it returns a 415 Method Not Supported HTTP response.
If it *does* support the GET method, whether the binding turned the
naked URI into your magical GET SOAP message and handed this off to
a SOAP processor or whether there was just a Servlet or CGI that
invoked some logic and generated a SOAP message to be returned on
the HTTP response is purely implementation detail about which SOAP
has nothing to say, correct?


> is implemented as a SOAP endpoint or merely an HTTP server.  If we want to 
> distinguish these cases, we can make appropriate use of SOAPAction.
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
> 
> 
>

Received on Friday, 26 April 2002 12:27:09 UTC