Mark Baker brings up an important aspect of the WS-* vs. REST situation that I've been hoping to speak about myself:

Yes, absolutey, we'll need the capabilities that the WS-* stack provides (for the most part). But do we need the WS-* stack itself to provide those capabilities? I'm certainly all for trying to reuse existing specs where that makes sense. The issue though, is that with most of them, they explicitly or implicitly require disregarding a key constraints of REST, disrespecting Web architecture, or both. WSDL's probably the poster child for this, as its raison d'etre is primarily to encourage rejection of REST's uniform interface.

Right. The problem with WS-* isn't that its trying to solve the wrong problems or that nothing valuable has been produced. The problem is the general disregard for existing web architecture. WS-* tried to take a revolutionary approach to something that required only incremental improvement. HTTP and URIs were treated as legacy technology that would provide a quick and dirty mechanism for bootstrapping this special next generation of web technology.

The REST advocates' criticism of WS-* generally comes off as an attack on technology or architecture but what really pisses the REST people off is the WS-* approach. From the beginning, WS-* has been approached incorrectly. The approach that we're advocating is to first embrace and understand existing web architecture and then to gradually enhance (constrain) it to meet the needs of new requirements. We advocate this not because we think it's a better way to be successful, we think it's the only way to be successful.

An example of the approach we're advocating is Bill de hÓra's recent proposal for reliable messaging over HTTP, (HTTPLR). The difference between the HTTPLR approach and the WS-ReliableMessaging approach is that Bill's proposal builds on simple proven web architecture without requiring additional apparatus.

Anyway, what we need to learn from this is that most successful technologies aren't successful on accident. HTTP and URIs were generally understood only at a very technical / bits-on-the-wire level -- the RFCs existed but Roy Fielding's architectural description came much later and I think it hurt us. We didn't understand how HTTP and URIs formed an overall architecture and how vital that architecture was to the success of the web. If the larger technical community had had an architectural understanding of the web, we might not be in such a mess.

What many of us are now wandering (and have been wandering for some time) is how much longer WS-* is going to continue down a path of incompatibility with web architecture and whether the work that's in progress or that has been completed by WS-* can be reconciled to work under the constraints of web architecture. The feeling I get is that a lot of the REST advocates feel so spited from years of being ignored that they would rather sit back and watch the WS-Building burn to the ground and build from scratch, which is unfortunate for everyone really.