Craig Andera has the details, but the bottom line is this: the MSDN document library is enormous (and I mean really big – the MSDN Library contains all of Microsoft’s product technical documentation for developers but now any client can access all the MSDN2 content via the API.
But why? Well, I think John Mollman nails it:
“I think this is a pretty big deal; we’re opening up the corpus of MSDN’s developer documentation to clients outside of our control and I’m confident that usage scenarios we’ve never imagined will emerge as folks play around with these services.”
This last point is the point. The MSDN team simply doesn’t have the resources to the provide the most optimal UI into all this content. In the world of Search > Browse > Subscribe, the content is already searchable (the majority of incoming MSDN traffic comes via search engines on the web and within the Visual Studio client). On the ‘subscribe front’, the RSS feeds provided are only as good as those provisioned – again, the RSS interfaces can only be as good as those provisioned, therefore throttled by internal resources. And an awful lot of browsing goes on too – but one can only browse the UI that’s been designed: the main library table of contents (TOC) and the Developer Centers (providing views into the library from a product / technology / scenario perspective).
Now, outside of the MSDN site exist thousands (probably 10s of not 100s of thousands) of websites pointing to specific pages of the library, providing their own UI into the content. However, without an API, the process of finding the right content to point to and maintaining those links for those (and clients) is a PITA. With an API the potential exists for some very cool stuff to be done. It unlocks the content – it frees the data – for others to do programmatic stuff against the content – search, combine (and re-combine) – new UIs and mash-ups!