MS Ignoring developer demand for REST tools?

  • Article

The long running PR battle is heating up again between those who advocate the implementation of service architectures [1] "RESTfully" using XML transferred via HTTP, vs those who work with SOAP, WSDL, and the specs built on them known as "WS-*".  The item that finally got me to blog about this painful [2] subject was James Governor's SOAP is boring, wake up Big Vendors or get niched

Evidence continues to mount that developers can' t be bothered with SOAP and the learning requirements associated with use of the standard for information interchange. ...Developers are turning their backs on the standard. Folks that is, building interesting information splicing apps--semantically rich platforms like flickr and Amazon are being accessed by RESTful methods, not IBM/MS defined "XML Web Services" calls.

Yesterday my partner Stephen issued a wake up call for middleware and tools vendors - give developers what they want , not what you think they should have. ...

One big question is why haven't IBM and Microsoft responded? The obvious answer is vested interest. When you have "bet the company" on a technology stack its kind of a drag to have to respond to something else.

A few thoughts: For one thing, I'd note that Microsoft  has responded to this need ... in about 1999.  The XMLHTTPRequest object implemented since the second version of the MSXML library provides such a powerful and convenient way to use XML and HTTP together that this API has been implemented in competing platforms, and was featured in an XML.com article just last week.   Forgive us for not touting Microsoft's support for this newfangled "RESTful" approach, I guess people here thought it was old news :-)

Second, flickr and Amazon are definitely "semantically rich" platforms, but they don't have the pain for which WS-* offers an analgesic.  Plain ol' XML over HTTP works just fine, and WS-* is overkill, in situations where:

  • information is public and encryption/authentication are unnecessary;
  • all communication visible to the service consumer is done over one protocol, HTTP; 
  • nothing terribly bad happens if a message is lost or duplicated;
  • and there are few demands for multi-part transaction management beyond what can be implemented with HTTP sessions or cookies. 

Users of browser-based applications come to expect the quality of service one associates with the Web.  Web services toolkits such as Indigo  on the other hand, are oriented toward use cases that demand high-security, support for existing enterprise messaging systems, message failure is not an option, and industrial-strength transaction processing is assumed.  The REST approach (as far as I can tell after years of discussion) assumes that all these features are provided at the application level rather than being provided by the infrastructure.  I am convinced that developers with demanding requirements for security, reliability, transactions, etc.  generally DO want what WS-* and Indigo promise.  Perhaps there is some way to offer these services within a RESTful toolkit so that application developers don't have to wrestle with them.  The obvious answer, however, is that few people seem to have much of a clue how to do this.  Those who do, such as the developers at Amazon, have invested fortunes in making it happen.

Third, it is true that IBM and MS have bet heavily on web services technologies, but at least after the initial flourish of web services hype in about 2001, they have not touted them as the balm for all web developers' pain.  Instead, they are driven by the requirements of enterprise developers who need to both preserve their investments in complex legacy systems that actually work while moving to integrate them with cheap, powerful, and ubiquitous desktop and internet systems.  RESTful success stories such as flickr and Amazon tend to have build built from the ground up for the Web, whereas the target audience for WS-* generally does not have that luxury.

Finally, REST advocates like to paint an appealing picture of a Web governed by open standards that mesh well with one another and over which XML documents conforming to industry-standard schemas with well-documented semantics are transferred.  Few who actually work down in the trenches suffer from this delusion for long.  Even a dirt-simple idea such as the XML format RSS becomes an interoperability mess in practice.  Our former team member Dare Obasanjo often writes about the challenges of implementing his RSSBandit aggregator in the real world web, and Mark Pilgrim https://www.xml.com/pub/a/2004/07/21/dive.html   and Sam Ruby https://intertwingly.net/slides/2004/devcon/ offer an even bleaker picture of the realities.  Once again, it appears that REST is a fine idea for simple scenarios where bad stuff can happen with impunity and corner cases can be disposed of arbitrarily.  Building secure and reliable applications for situations in which serious money or human lives are at stake is another matter. 

Nevertheless, the WS-* specifications and the tools that implement them are in the domain of the Indigo team, and Don Box is quite able to take care of himself in a PR fight :-)  (Check out his post on service contracts in Indigo ... and read the comments and trackbacks before believing that MS is not offering developers in this are what they want!). The Indigo folks are a customer for the WebData XML tools, but so is anyone building a RESTful  application in the MSXML or .NET environment. I'm not trying to take sides in the REST vs WS-* debate, just trying to keep the debate centered on the real capabilities of XML over HTTP and the real challenges that WS-* is addressing.

What is most important to our team is understanding what challenges people are having working with XML,  and in interacting with programs, databases, and the Web to generate, store, and retrieve it.  We want to understand what our users need and want in XML toolkits so that they can do their work better and faster, whatever their position (if any!) in the REST debate. 

Mike Champion

updated:  Dare Obasanjo amplifies what I was trying to say: "I believe this makes it clear that we at Microsoft understand that POX, SOAP, and WS-* each have a part to play in the world of XML Web services. "  His comments section gets some good feedback from the Redmonk people:  James Governor writes 'I am happy for MS to make a strong claim to web services pluralism';  Stephen O'Grady writes 'maybe it is "old news" to you guys, but i think a bit of messaging around RESTful approaches would not go amiss'. 

[1] It is hard to even identify the debate without getting into arguments about labels. One often sees this described as "web services" or "SOAP" vs "REST", but that's not really correct:  All of these things are about services offered over the web; SOAP can be used in a RESTful way, and many of the "plain old XML over HTTP" examples one sees cited as REST success stories do not even come close to meeting the constraints of the Representational State Transfer architectural pattern described by theorists.  The MS "Introduction to the Web Services Architecture and its Specifications" provides the best overview of "WS-*" that I know of, and the Wikipedia article on REST provides a nice coherent overview. In this post, I'm going to avoid the urge to be pedantic, and use "REST" to mean the design pattern of  transmitting ordinary XML over HTTP without the use of SOAP or WSDL.

[2] I spent two years on the W3C Web Services Architecture Working Group, most of that as a co-chair, and the debate between the SOAP/WSDL/WS-* developers and the REST advocates took up a disproportionate amount of time and energy.  The final document released about a year ago is a heroic if apparently doomed attempt to reconcile them.