Recently I’ve been quite busy at work, doing lots of interesting social software related projects with various customers. In the middle developing non-technical methods, I have sticked my fingers back into tech side by implementing some nifty Web 2.0 blogging APIs into our Dicole Knowledge Work Environment software. Dicole now supports Blogger API, MetaWeblog API and MovableType API, which are all XML-RPC based. This opens up great possibilities in the organizations I work with, including mobile blogging and one-click publishing.
During that process I tested over 50 client software components (on platforms like Windows, Mac OS X, Linux, Pocket PC, Palm OS, Java, Web services etc.) that support the mentioned APIs. My review must have been the most extensive to date done by anyone. I took notes while I progressed so I might release a paper later on the various tools and my experiences with them.
Regarding the APIs, I have to say it’s a total mess. Blogger API was first, then it was extended by MetaWeblog API, which was further extended by MovableType API. The design of those later APIs is just to patch the previous API, rather than fixing the problems for good.
One serious problem is return error codes. If an API call fails, there is no consistent way for a client software to take action based on the error codes, as there is no standard set defined anywhere.
Another is appkeys (for tracking API usage) introduced by Blogger API. As other APIs build on top of Blogger API and ignore this feature, the way you call the API is highly inconsistent.
Uploading media through the API encodes the data with Base64. This makes the upload about 30% larger than with binary uploads would be.
The APIs are also lacking some fundamental features that would enable creation of much more powerful client tools.
Because of these and many other reasons, the client software products often interacted inconsistently with the APIs. Some supported UTF-8, some didn’t. In some tools you could select multiple categories, in some only one. Some had support for HTTPS connections, most didn’t. Rarest was support for server authentication methods.
There is also one fundamental problem that also plagues almost every other Web 2.0 API out there, and that is proper authorization. Often username and password go over the wire in plaintext, easy to interpret and steal by anyone. Often these access credentials also give full access to the software through a web interface. There are no temporary access keys. There is no limited API access. It’s all or nothing and the APIs implement no calls to check for available methods (expect MovableType API, but I believe the feature is not implemented by many client implementations). If I use third-party web services like Flickr to access my blog, I can’t authorize Flickr for access only once, it’s all or nothing. My password will be in their database. I can’t block or limit Flickr from the API side as there is no way authenticating the service provider accessing the API.
Despite their flaws and hackish nature, these APIs open up the gates to innovation, service provider interoperability, usability, productivity, even indepence as you can change the provider while your working interface remains the same. For me it means I can just hit F8 and start typing, even offline, and then choose where this post goes in the twenty blogs I contribute to. Right now I work over an unstable 3G connection through my mobile phone, so I wouldn’t trust any web interface for this text, but I can trust my client software.
Tags: Web development