Sanjiva Weerawarana, one of the primary people responsible for the SOAP and WS-* specifications, defends them in an interview with InfoQ’s Stefan Tilkov:

InfoQ: Interview with Sanjiva Weerawarana: Debunking REST/WS-* Myths

Tilkov is a fairly hostile questioner, obviously arguing the REST viewpoint. Weerawarana provides calm and rational answers, though I don’t necessarily agree with them. Here are what I think his key points are, along with my responses.

SW: WS-* will cease to be an incomprehensible jumble of standards once Microsoft releases WCF, which will provide a straight-forward reference implementation. This does not mean that it will be a proprietary Microsoft standard because WSO2 (Weerawarana’s company) will release a reference implementation for other platforms. Implementations by Sun and others are incomplete and will go nowhere.

It sounds to me like it’s Microsoft or nothing then. I can’t see many big companies going with something from WSO2 (which the CIO has never heard of).

SW: REST is great at what it does, but it doesn’t provide standard ways to do things like authentication and authorization that some applications require.

Uh-huh. And what sort of applications are these?

SW: For example, ordering multi-million dollar items like jet engines over the web.

In other words, things that nobody actually wants to do yet. (And if someone wants to do them, they might arguably do better to evolve a solution on top of REST.)

This is a classic example of creating a standard to solve a hypothetical problem, then trying to implement it afterwards. Among other things, this ensures that the problems with the standard will only be discovered when it is too late to fix them.

SW: Most of the popular web applications like Internet banking and Google Maps are not RESTful.

This sounds like a red herring. What we are discussing here are alternate ways to implement programming interfaces (APIs) not user interfaces (UIs).

SW: REST is tied to HTTP. WS-* is protocol independent.

But HTTP is what everyone wants to use at the moment. They may be better off with an approach that works great with HTTP, instead of an approach that works clunkily with a lot of protocols.

SW: Toolkits like WCF will allow you to implement a service once and have it display multiple APIs: WS-*, POX, HTTP GET, and JSON.

And this is a good thing because…? It probably means massive additional complexity and confusion, and none of the APIs will work well.

SW: Addiing new features to REST requires the use of cookies or URL-rewriting, both of which are ugly and problematic.

“Cookies” are a special case of passing extra data in HTTP headers. This is a perfectly reasonable approach to extending REST.

SW: SOAP started out as RPC over the Web, but that was a mistake. WS-* today has nothing to do with RPC, so it is unfair to bring up the many failures of distributed RPC.

It’s true that the standards don’t require anything like RPC. But if you look at the actual toolkits that are needed to use WS-* (particularly WCF), at the documentation and marketing materials and instructional materials, it’s all RPC, RPC, RPC. So any applications built with these toolkits will tend to be RPC over the Web, with all the problems that entails.