In his post Maybe a better posting api is needed  James Robertson writes

I've had harsh words to say about Atom in the past, but that was mostly over the feed format. I haven't looked at the posting API yet - maybe I should. The Blogger API and the MetaqWebLog API are simply nightmares. There doesn't seem to be any standard way for client tools to interact with a server - I was debugging the interaction between a client and my server last night via IRC. Even better - the client was set to use the MetaWebLog api, but was sending requests to blogger.apiNameHere names. Sheesh. There was also an interesting difference in api points - I had implemented 'getUserBlogs', and the client was sending 'getUsersBlogs'. A quick Google search turned up references to both. Sigh.

I implemented both names, pointing to the same method. I had to map blogger names over to MetaWebLog entry points, at least for the tool being tested last night - who knows what oddness will turn up next. What a complete mess...

I've been similarly stunned by the complete and utter mess the state of weblogging APIs is in. As I mentioned in my post What Blog Posting APIs are supported by MSN Spaces? one of my duties at work is to investigate the options and design the blogging API story for MSN Spaces. In doing this, I have discovered all the issues James Robertson brought up and more. Mark Pilgrim has an ApacheCon presentation entitled The Atom API which highlights some of the various issues. One of the lowlights from his presentation is the fact that the MetaWeblog API spec significantly contradicts itself by stating that the data model of structs passed between client and server is based on RSS 2.0 then includes examples of requests and responses that show that it clearly isn't.

My personal favorite bit of information that can only be discovered by trial and error is the existence of the blogger.deletePost method which isn't listed in the Blogger API documentation but is supported by a number of blog posting clients and weblog servers.

I can't believe that anyone who wants to write a client or server that uses the standard weblogging APIs has to go through this crap. It almost makes me want to go join in the atom-protocol discussions. Almost.


Thursday, March 3, 2005 4:00:42 PM (GMT Standard Time, UTC+00:00)
Its not even as if the problems start there. The subscription experience is already an absolute mess. Trying to get a non-techie to subscribe to some feeds is not an easy task. Some responses..

Why do end users care that it is XML? Why do they need to know what RSS is? Why do they typically get shown junk (XML) when they click on the orange XML button? How do they know to click on the orange button? Why do they then have to cut and paste urls?

I think that just shows that trying to define a process by word of mouth and conversations doesn't work, neither do protocols scratched on the back of a cigarette packet.

I'd ask you to at least start a discussion with the Atom guys, the whole process might be slow (and will no doubt not be perfect) but at least there is some consensus.

I realise there are two issues here (end user experience and/or publishing mechanisms) but they both need to be fixed.
Thursday, March 3, 2005 7:05:30 PM (GMT Standard Time, UTC+00:00)
Why not use the web page data to create blog posting tool? I manage to create one for dasBlog, a very basic one for now.

Take a look at my technology, is really all in the web pages, no need to create protocols to blog post.
Thursday, March 3, 2005 7:23:45 PM (GMT Standard Time, UTC+00:00)
But Wait, There's More.....

Based on my experiences writing a mobile blogging client I recently posted my own grizzle:
The thing I felt moved (OK, not so much moved as nudged slightly) to comment on was the fact that the major APIs provide methods to return the *entire bodies* of recent posts, but they won't give you a simple list with date/time, title (where present) and associated Id that you could then use to retrieve for editing purposes just the post you are actually interested in. This is a real pain in mobile scenarios where people are typically charged for traffic (and bandwidth is often limited). You shouldn't be forced to download data most of which you won't want. This is elementary Doing Things With Lists Of Stuff When Resources Are Not Infinite, and frankly I'm surprised it's handled so badly (or rather, not handled at all).
Friday, March 4, 2005 5:16:27 PM (GMT Standard Time, UTC+00:00)
> It almost makes me want to go join in the
> atom-protocol discussions. Almost.

You should. The list could always use more pragmatists.
Tuesday, April 4, 2006 12:23:42 PM (GMT Daylight Time, UTC+01:00)
I want mp3 player. What will advise?
Comments are closed.