Kevin Daly

Key omission from weblogging APIs

The Blogger API and the MetaWeblog API both have their quirks and failings, but on the whole they do a reasonable job for what they set out to do.
There is however one area where they both fall down badly in my experience:

If I want to provide a facility for people to edit or delete posts they have made previously, obviously it is necessary to present them with a list that they can select the relevant post from.
Both the Blogger API and MetaWeblog API have a method called getRecentPosts. This retrieves n recent posts where n is a number passed as a parameter.So far so good.
The problem is that they retrieve the entire body of each post: there is no listRecentPosts method. This is a very sad omission, and frankly quite hard to understand. Whenever one of a number of things may be selected for editing, it will be necessary to present the user with a list from which they can select the item in which they are interested. It is a given that the chances are that any entry that a user does not select, they are not interested in (otherwise they would have selected it)....so why retrieve more data than is needed? Several times more data than is needed.
To identify an entry to the software and to the user all that is required is title, date/time and id.
It is easy to see that Blogger is constrained by its lack of provision for titles, but MetaWeblog would be perfectly capable of providing a list of this information in a useful format - in its case the omission seems to be “for historical reasons”.
This is not simple pickiness - if your connection to the blog server is via a cellular network (for instance, from a Pocket PC Phone Edition device or a laptop or tablet using a mobile phone as a modem), chances are you are paying dearly for traffic, in which case you definitely do not want to be retrieving data that you are not interested in.

I've mentioned the specific example of the Blogger and MetaWeblog APIs, but sadly this is a common omission: the brand spanking new BlogService web service provided with the soon-to-be-released Community Server is likewise limited to a GetRecentPosts method that returns the entire body of each post.
It's all a bit sad really.

OK so I've had my grizzle, but do I have any constructive suggestions?
I think Blogger is pretty much in a corner owing to other design decisions (and I assume the emphasis there is on the Atom API from now on - that's a can of worms for another time).
I see no reason why MetaWebLog couldn't be extended (for all I know it has been in implementations of which I am unaware), but the problem would be to get such an extension picked up by enough implementers to make any difference (I'd be happy enough if a few blog tool providers would just implement newMediaObject - the early versions of APIs acquire/create a lot of inertia).
On the other hand, anyone writing their own API (whether implemented as a web service or whatever) has a golden opportunity to get it right. People might even thank you for it (unless I'm the only person in the universe who is bothered by this at all, which is admittedly true of quite a lot of things).
As a last, not ideal but sort of workable option, it would also be a pretty trivial task to write a web service that would accept a user's credentials, a blog address, blog id and number of posts, issue a metaWeblog.getRecentPosts call to the blog hosting site and then send a slimmed-down version of the result to the client, but obviously the site hosting such a web site would need to be able to handle the traffic (there would also be security issues, but that's true of most current blogging APIs in any case).