Ah, gotta love permathreads. 8-)
Stefan did such a fine job with his response, that I think I’ll just “+1” it (yes, including the agreement with Chris, gasp! 8-) rather than respond myself. Thanks, buddy.
I also wanted to add, in response to Chris, that I only brought caching up as an example of something in HTTP that wouldn’t make sense to have if its application semantics didn’t include GET. I didn’t mean to imply that caching couldn’t be implemented without modifications to SOAP. I was actually specifically thinking about two changes to SOAP which would be required for a couple of important optimizations, both having to do with coarse grained messaging, as SOAP is intended to support. The first would be a framing optimization, the “jump” feature (akin to a chunked transfer encoding). The other would be a push away from strictly interpreted XML, since XML doesn’t support streaming due to the fact that an application can’t make much in the way of forward progress until the end of the message has arrived, lest the message end up malformed.
I also just noticed this MEST response from Steve where he realizes that MEST seems familiar;
The issue was that for at least some people, that paradigm shift had already happened and confusion arose when it was given an unfamiliar name.
Hmm, there’s seems to be a lot of that going on. 8-) It’s why I’ve claimed for about 5 years now, that the Web is what Web services is trying to be. It’s also why I argue that MEST is a specialization of REST. Or, in Steve’s words, that “every behavioral entity works by processing messages” is a special case of “every resource is a container for state”.