The Butt Ugly Weblog

Why all APIs are not equal

People ask the question: why is the MetaWeblogAPI (MWA for short) not sufficient for wikis as such?

I guess it's possible up to a certain extent, but there are a few reasons why I think it's still a bad idea:

• Versioning. Supporting the versioning inherent in many Wikis would need a new field to be added in the MWA getPost().
• getPost() does not define in which format the page should be returned (WikiMarkup, HTML or something else). Again, a new field is required.
• A method to get the links from a page is highly useful for things like the JSPWiki:TouchGraphWikiBrowser. Wikis inherently refer to themselves much more than weblogs, so it's only natural to reflect this in the API as well.
• Forward and backward links are a bit of a problem as well: In order to do other things like basic edit/view, you would need to be pretty good at guessing the format of the URLs as they come in the rendered HTML. This is why there's the href -field in the WikiRPCInterface.listLinks(), btw. For an example of this in action, see http://www.mahlen.org/jspwiki.
• There is no way to download attachments. While there's a way of uploading using the MWA newMediaObject(), there's no corresponding getMediaObject().

If the getPost() would have a struct as one of its parameters, then some of the above things would not be a problem, since you can pretty much add arbitrary fields to a struct without breaking existing apps. However, this is not the case, and you would need to embed the version number in the "blogid" parameter. This is clearly a kludge, and very, very fragile.

Don't get me wrong; I'm all for interop and stuff. And frankly, there's no reason why a wiki shouldn't support a MetaWeblogAPI as well (JSPWiki does), but I think that in order to gain the most out of a Wiki, you need an API designed for the strengths of wiki technology and does not treat it as a bastard offshoot of weblogs :-).