Hmmmm .... so I'm at a loss here. Help me out. This is very
interesting.
How would this work then? You just use HTTP as a way to send SOAP
messages but in the SOAP you'd have defined set of uniform methods/
operations?
Would this uniform set be defined by some standards body or would it
be proprietary to every organization?
[E.g. could someone have READ, UPDATE, CREATE and other have GET,
CHANGE, NEW?
These would be uniform in an organization but not outside an
organization. So one could imagine that two financial services
organizations merge or something and then you'd have two different
sets of operations.]
I feel I'm growing some more on this thread, thank you.
William
On Jul 23, 2007, at 11:40 AM, Mark Baker wrote:
On 7/23/07, William Henry <[EMAIL PROTECTED]> wrote:
>
> Hi Henrik,
>
>
> I'll wait for the RESTafarians to address your first point on
Myth #3, but I think that they'll have a couple of things to say.
My guess is that they'll take exceptionto what it sounds like your
saying - multiple methods implying a richer semantic set than GET,
PPOST, PUT etc.
Nope, no exception here. Even from a purely REST POV, what's
important isn't the number of methods, it's their uniformity. That
HTTP has just a handful of methods is a consequence of this uniformity
(i.e. maximal generality), not an explicit design goal.
> And your second point on myth #1 seems to confirm this. I think
your saying that you'd use GET to move SOAP messages that might
come from a semantically rich set of operations. It sounds like you
are missing the RESTful approach and are falling into the REST-RPC
group.
>
>
> Mark? Care to comment? Am I reading too much into Henrik's post?
DSSP uses SOAP in the way I was espousing since before the XMLP WG
began . Henrik gets this stuff (long before I did, even 8-).
Mark.
--
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Coactus; Web-inspired integration strategies http://www.coactus.com
