First a bit of background. The MetaWeblog API descripes a set of remote procedure calls invoked via XML-RPC for interacting with a weblog engine. One can perform actions like post a new entry, edit an entry, and retrieve an entry using the API. This means that people can use weblog clients such as W.Bloggar and Blogert to edit and post their weblog entries to any blog server that supports the API. I had planned to implement this API for RSS Bandit so I could also turn it into a blog client but decided against it due to significant issues with the MetaWeblog API and its ilk.

Below are the top three reasons I decided not to implement the MetaWeblog API (or any other of the current crop of APIs for posting/editing weblog content) in RSS Bandit but instead have decided to help Sam Ruby in making Echo come to fruition.

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. Strongly Coupled To XML-RPC: RSS and Joe Gregorio's CommentAPI have shown that one can build applications that retrieve and send XML documents from client to server directly using HTTP GET and POST instead of going through an added layer of indirection by using exlicit RPC mechanisms.
   
   One can retrieve messages with HTTP GET and send them with HTTP POST. More importantly this means that other facilities can be layered upon the message format without having to complicate it. For instance, security can be handled with HTTP authentication instead of having to unnecessarily complicate the API. Tracking user identity can be done using HTTP cookies instead of placing application IDs in the actual message format like the original Blogger API did.
   
   Both the Blogger API and the MetaWeblog API are extremely influenced by the RPC paradigm instead of being influenced by the technologies that are part and parcel of the WWW.
   
   I also believe that there should be the API should not just be tied to XML-RPC but should have interfaces that utilize the XML Web Services family of technologies like SOAP and WSDL not just XML-RPC. There are many products and toolkits that support SOAP/WSDL/etc plus more are being built every day. It makes little sense to me that almost everywhere else in the software industry people are either exchanging XML documents using RESTian principles (i.e. HTTP GET and POST) or the XML Web Services family of technologies but when it comes to web content related technologies there is this anachronism where an arbitrarily different methodology is used.
   
   This is not to say there aren't historic reasons for XML-RPC's predominance in this area but that in today's world there is no reason why industry proven methodologies cannot be adopted in tandem with the existing infrastructure.
   
   
3. 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. For instance there should be APIs methods for
   
   
   • Retrieving entries based on a search criteria (title, date, category, etc)
     
     
   • Posting comments in response to someone else's blog entry
     
     
   • Updating one's user information.
     
     
   • Managing one's visible blogroll.
     
     
   
   
   

To put it simply, the MetaWeblog API is a good first draft of a blog editing/posting API (which is not far from the truth since it is just a refactoring of v1.0 of the Blogger API) but it has significant issues which cannot simply be addressed by tweaking a method parameter here or a return type there.

It is time for evolution to take place. Most of the weblog community realizes this and is working together to make this evolution happen. Sadly there are some who view this as a disruption of their legacy and instead of helping are attempting to destroy the project. This is very unfortunate.