December 2, 2004
@ 04:36 PM
Comments [9]
What Blog Posting APIs are supported by MSN Spaces?

I've seen a number of people ask if MSN Spaces supports any web service APIs such as the Blogger API or MetaWeblog API that allow users to post to their blog from applications such as MarsEdit, BlogJet and w:bloggar.  This question has been asked in blog posts by a number of people including Robert Scoble, Don Smith and Roland Tanglao. Like every question there's a short answer and a long answer.

Short Answer: There is currently no support for any web service APIs for managing ones Space. We are investigating the feasibility of supporting a web service API which enables our users to manage their Space while not having to compromise on security which unfortunately is currently the practice in the blogging world.  

Long Answer: I listed the problems with the current crop of blog posting APIs such as the Blogger API and MetaWeblog API  in my post from a year and a half ago What's Wrong with the MetaWeblog API? . The main issues for us working on MSN Spaces are  

  1. Security: The MetaWeblog API has no concept of security. Passwords are sent in plaintext as parameters to XML-RPC functions (i.e. they are sent in plain text on the wire as part of the XML message).
  2. Limited Functionality: The MetaWeblog API only allows one to either post and edit blog entries, fetch information about a specific user or change the website template. This is a drop in the bucket considering all the things one would like to do with a weblog engine which can be supported by the engine.

The security issue is a big problem and we do not plan to compromise on it. Although it may be satisfactory for certain services to exchange user's passwords in plain text where they can be sniffed by malicious third parties we don't want the Passport accounts of our user's exposed in such an insecure manner. This basically means we can't plug into the ecosystem of tools and services built around blog posting APIs today.  

Already the current beta version of MSN Spaces has more functionality than is exposed by APIs such as the MetaWeblog API. For example, it would be difficult to imagine how one would manage their music list with just that API. Add to that the fact that we are planning to add more features in future versions that also have no useful analog in that API.

I plan to present 3 choices to folks at work on what we should do in this regard. The choices I see in order of preference would be

  1. Support Blogger/MetaWeblog API over HTTPS/SSL: This would involve the most minimal change to various blog posting tools to support MSN Spaces yet would give our users the security they desire. Unfortunately it doesn't solve the problem that these APIs don't expose all the functionality of an MSN Space.
  2. Support an MSN Spaces specific API over HTTPS/SSL:  This would allow us to build an API specifc to our service such as has been done with the MovableType API or the LiveJournal API . The downside is that it would mean developers would have to do a lot more work to suupport our service but would expose richer functionality than if we just supported the Blogger/Metaweblog APIs. This would lead to less tool support but I suspect the most popular tools would support our API. 
  3. Support the Atom API over HTTPS/SSL: The IETF's Atom Working Group is working on a new common  API for blog posting which they hope will replace the aforementioned blog posting APIs. I have questions about their delivery timeframe given that its been over a year and a half since Sam Ruby kicked of the Atom effort  and although their schedule has them shipping the spec in a few months they are still having debates on fundamentals such as whether the Atom protocol should be based on WebDAV or not. Having worked on the XML team at Microsoft and watching I have seen what happened when we spent years working on technologies like XInclude & XQuery which are in active discussion only for them to drag out so long that they couldn't fit in our ship schedule so we cut them thus wasting the effort.  Secondly, still has the problem that it won't expose all the functionality of an MSN Space. I don't have much faith in this option but have put it on the list for completeness.

I should note that there is also the question of whether it makes business sense to do support blog posting APIs. Mike will be the one making the business case pitch to folks over here while I'll be making the technical pitches. It would be interesting to know what percentage of users actually use a rich client versus using the Web interface for editing their blogs in existing systems.

Anyway, your thoughts and feedback are welcome. I'd especially love to hear from authors of blog posting tools.  


 

Categories: MSN

« Top 5 Things I Dig About MSN Spaces | Home | Why MSN Spaces and not MSN Blogs? »
Thursday, 02 December 2004 17:03:46 (GMT Standard Time, UTC+00:00)
Dare, the schedule has the spec going to Last Call in 4 months, not "a few". That said, there are a number of issues that need to be settled quickly.

Secondly, it would be impossible for any standards-based blogging protocol to fully expose the capabilities of a large centralized service like MSN Spaces. My question is which functionality wouldn't be exposed, and if the nature of it makes it impractical to add an extension to the Atom protocol to cover it.
Robert Sayre
Thursday, 02 December 2004 17:28:12 (GMT Standard Time, UTC+00:00)
I can offer some empathy for the API issue.

Everyone goes on about the Blogging API's and they seem to think it's a one size fits all - every blogging engine I've seen has either added their own extensions to the API *or* just went their own way when implementing the API as described so it ends up half baked, at best. Never mind the fact that the MetaWeblog API returned the most convoluted XML responses that I've ever imagined possible... it's almost impossible to consume and different web sites send the responses in different orders and/or cases. It's a potential nightmare from a client point of view.

This is one of the reasons why I made my own posting tool (SharpMT) in the first place: most posters were too generic in their approach to properly target MovableType (or now TypePad) so I wrote a custom app to target that specific engine. While it was limiting, it did what I needed it to do, so I've been happy with it.

(That's not to say I wouldn't contemplate doing a port of it for Spaces - it's just beyond the scope of what I've done so far)
Randy
Thursday, 02 December 2004 20:14:47 (GMT Standard Time, UTC+00:00)
I don't see the problem with so-called half-baked APIs. The basic functions that are used 95% of the time are available in the defacto-standard APIs. Take my mobile blog client for example: All people really want to do is write a post and maybe include a picture. All the bells and whistles of Spaces are probably not very useful in that mobile context and would be difficult to implement in a resource-limited device.

What not expose the basic functions via the available APIs and let the users do all the other stuff with their web browser or a custom client?

As to security: https support would be sufficient and easy to implement on both client and server.
Dennis Luemkemann
Thursday, 02 December 2004 20:26:35 (GMT Standard Time, UTC+00:00)
A fourth possible option might be to develop a Spaces-specific API but based on RESTful HTTPS and whatever XML languages you're already using - RSS or whatever. This should be quick for you to implement, but also comparatively straightforward for third parties to hook into (they might have to take their Atom format and sling it through XSLT before POSTing, big deal).

btw, Joe's just got a piece at xml.com on the subject:

http://www.xml.com/pub/a/2004/12/01/restful-web.html
Danny
Thursday, 02 December 2004 22:42:51 (GMT Standard Time, UTC+00:00)
You'd think Microsoft would *love* the idea of using an OS-specific .net-based rich client for blogging.

By "makes business sense" I assume you mean loss of ad-sales but come on, that's a drop in the bucket for Microsoft. Time after time you've chosen brand-strengthining over short term profits, why would that change now?

Shane
Shane Harter
Friday, 03 December 2004 01:43:22 (GMT Standard Time, UTC+00:00)
I have a LiveJournal account, and most of my activity (posting, administration, reading comments etc.) is done through a custom client, not through its web interface. Similarly, I use w:bloggar to post to my dasBlog setup, although administration has to be done using the web interface.

My main reason for doing so is partly because there are clients that support rich functionality, such as Semagic, but also partly because all (or most of) the functions I need are available in 1 convenient location without having to navigate several different pages of a site (and wait for each of them to load).

My personal preference would be for MSN Spaces to support both a standard API (either Blogger or MetaWeblog) and its own custom API (for additional functionality).

Damit
Damit
Friday, 03 December 2004 23:26:57 (GMT Standard Time, UTC+00:00)
+1 for blogger/metaweblog API & a custom one. This lowers the bar for entering into the space of, er, space editing while giving richer functionality to those who want it.

While Joe Six Pack might not know (or care) about the difference between a desktop and web client, it gives those of us who do a chance to use the established functionality of the older apis. They also become no hassle as the apis are already out there, but you still have the chance to evolve the spaces-specific api.

So, I vote to have cake and eat it too!
Chris Frazier
Saturday, 04 December 2004 06:40:43 (GMT Standard Time, UTC+00:00)
Extend the ATOM API to support extra features. This approach builds on prior work and shows leadership, since you can expect other blog vendors to follow suit on both the features and API.

Until then, option 1 looks good (80/20 rule).

About the business case, few know more than Microsoft about the value of an ecology of third party developers.

- phil
Phil Wolff
Monday, 20 December 2004 01:29:29 (GMT Standard Time, UTC+00:00)
For purely selfish reasons (I wrote a Windows Mobile blogging tool originally for .Text to which I'm in the middle of finally getting around to adding support for the MetaWeblog API, thereby possibly broadening its appeal) I think MetaWeblog API over HTTPS/SSL (make that SSL3, Please) would be ideal in the near term, even though I think XML-RPC is a crock of smelly stuff.
When it's settled down a bit the Atom API would be a good idea on the face of it...at least it isn't the same degree of XML soup as MetaWeblog. The last I knew the authentication scheme for Atom involved hashing (among other things) the password, so it would also be nice if you could delay that until the .NETCF 2.0 has been released (makes things much simpler) :-). But there *is* the problem of features not supported: for instance, for reasons known only to themselves many people feel the need to upload out of focus images of not particularly interesting things (OK, I'm being unfair), especially from mobile devices - I don't understand at the moment how Atom would support this, so from that point of view if you were on the other hand implementing the MetaWeblog API you'd definitely want to support metaWeblog.newMediaObject - which from a brief survey seems to be supported by very *few* of the existing blog engines that supposedly implement the API (neither .Text nor dasBlog implemented it, last time I looked - which coincidentally was a few hours ago).

Oh, and one last point: Does a blogging API *need* to provide access to every feature of the weblog engine itself? You really need to nail the use cases for something like this when deciding what to leave in and what to leave out - but then you obviously don't need me to tell you that.
Kevin Daly
Comments are closed.