Re: Issue 133, and permitting no body

> Anyway, if you see SOAP as being about message exchange (which I do) then
> what I was trying to do was think how you would describe that as a SOAP/HTTP
> application in REST like terms... ie. what do the resources model and how
> might one think of the messages as state representations - and not simply
> messages. I don't know that I have it right.

My view on this it is that SOAP provides an envelope that can
encapsulate a message.  But the *meaning* with which that message is
transferred rests (pun intended 8-) primarily with the underlying
protocol to which it is bound, but also to the SOAP features that
extend it (the end-to-end targetting model, and mustUnderstand).

Actually, this isn't a REST specific argument at all.  Every application
protocol exists to coordinate the tasks necessary for that application.
Each one accomplishes this by limiting the agreement that is made over
the network, because agreement between uncoordinated actors is *HARD*
and takes lots of time thrashing about in standards organizations.  HTTP
just happens to be able to do a lot more than other application
protocols.  Perhaps that's why it's confused for being a transport
protocol so often?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Monday, 4 February 2002 16:24:54 UTC