RE: whenToUseGet-7 Making SOAP Restful

PMFJI, see below.
>
> >>  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.
>
Not really very different IMO. Both proposals use HTTP GET - they are just
triggered in a slightly different way. Noah's uses a particular SOAP message
whilst Stuart's uses the absence of a SOAP message. Noah's "magic message"
can carry no headers or any additional information because it isn't actually
sent anywhere (HTTP GET has no entity body).

To me both proposals are a convention for triggering the HTTP binding to use
GET instead of POST, apart from that they are indistinguishable. You could
argue that the binding at the HTTP server reconstructs a "magic message" and
passes that to the SOAP processor, but as Chris pointed out that message
contains nothing apart from the instruction to get the resource anyway. The
result would be identical to a straight GET.

> 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.
>
How can it be extended to be used with other SOAP headers if it isn't
actually sent anywhere - did I miss something ?

Regards,
Marc.

--
Marc Hadley <marc@hadleynet.org>

Received on Saturday, 27 April 2002 06:02:47 UTC