Microsoft needs REST
Apparently, Microsoft is diverging from the rest of the Web 2.0 world on how to approach integration and mashups. REST (Representational State Transition) is an architectural style that is transforming how systems integrate together, but it isn’t a standard. The ATOM Publishing Protocol (APP) is a popular RESTful standard used by Google and Yahoo among others to integrated services and manage publishing of information. However, Microsoft has taken exception to APP that everyone else is adopting and chosen to build their own protocol. Arnon Rotem-Gal-Oz has posted a good analysis of the give and take of the standards world and how Microsoft and the standards community have reacted. Microsoft needs to be able to integrate their web properties on Microsoft Live as Google and others have been doing for the last couple of years. The group according to Yaron Goland from Microsoft required a protocol for structured data and search and looked to ATOM Publishing Protocol (APP) given its popularity. Google in particular has run very hard with APP extending its GData service for reading and writing data from various Google data sources. This may in part explain Microsoft Live's need for a new standard as they compete directly against the services Google presents with GData. The result is that Microsoft has introduced Web3S for Web Structured, Schema’d and Searchable as a competing standard.
Microsoft needs a REST-style protocol to be able to provide the integration capabilities that Google and others provide and they need it to be open. Although APP has proven useful in publishing collections and items of blogs, calendars and podcasts, its model must be extended to be useful for other purposes. Dare Objasanjo from Microsoft makes a reasoned argument that APP lacks the ability to publish information beyond these types, lacks support for granular update to data fields and provides poor support for hierarchies. However, Microsoft’s conclusion that this requires an entirely new standard has been disputed by many.
As Tim Bray, the co-inventor of XML and Sun employee, noted that it is “unfortunate that the first time the world heard of Web3S it was in a post of Dare’s aimed at explaining APP’s failings.” Joe Gregorio, IBM employee and major contributor to APP, asked, “What I am more interested in hearing about is why you didn’t approach the WG (the IETF standards working group) with these issues when you ran into them?” The resulting discussion from the ATOM community has generally been critical and questioning of the value of Web3S. However, there appears to be no attempt on Microsoft’s part to correct any of the issues of APP in open standards forum.
Yaron Goland defended his Microsoft colleague, Dare Objasanjo, as a poor sitting duck. He justifies the decision to scrap APP as tactical and not strategic. He states: “We considered this option but the changes needed to make APP work for our scenarios were so fundamental that it wasn't clear if the resulting protocol would still be APP... I also have to admit that I was deathly afraid of the political implications of Microsoft messing around with APP.” According to Goland, “we couldn't figure out how to use APP without putting an unacceptable implementation and performance burden on both our customers and ourselves.”
The implications for this APP vs. Web3S debate can potentially be enormous. Just as we are on the brink of creating simple architectures that are interoperable using simple standards, the industry risks splitting into separate, incompatible camps again. It is probably no coincidence that we have Microsoft on one side and Google, IBM and Sun on the other. This will be a fundamental problem for enterprise customers if Microsoft extends this strategy into any REST architectures that it introduces into the enterprise. Any enterprise systems that expose their data using APP, which is likely in the near future, will be incompatible with any Microsoft system that expose their data with Web3S. On the internet, it will certainly make it difficult any web sites that are looking to provide consistent mashups with Microsoft’s web properties the way that they do with Google’s properties. This may be what Microsoft is trying to accomplish, but may end up being Microsoft’s bigger problem.
It is still early in this confrontation, but this tactical decision may be a strategic error on Microsoft’s part. The larger risk is becoming irrelevant in Web 2.0 or its successor. If Microsoft Live is difficult to mashup, the many web sites, commerce sites and interactive services that rely on mashups and integration to provide the user a richer experience will simply go to other alternatives, primarily Google. Even if Microsoft is correct in assumptions that it could not use GData types of approaches to extending APP, it doesn’t seem to be hurting Google very much.