I thought the Blogger Web service API and its close cousin the MetaWeblog API were interesting ideas. After attempting to experiment with them a bit I came to realize that their implementations where lacking the features or flexibility to take full advantage of MovableType features. For instance both APIs did not support MT's extends fields such as excerpt, "more text" and recently a keywords/meta data field. In the case of Blosxom, another blogging tool I use, implementing these APIs would be more substantial then the tool itself -- a disproportionate fit to say the least.
While (re)aquatinting myself with the concepts of REST architecture and other related thoughts, I began to consider how they could be applied to developing a flexible and scalable interface that was bettered suited for a wider range of publishing tools like MT and Blosxom. The thought has been bouncing around my head for months and then I saw the making of what I was thinking.
Joe Gregorio has opened The Well-Formed Web site begun work on a weblogging tool (dubbed RESTLog) featuring a Web service API based on REST architecture principles. (Nice work getting something out there Joe!)
While a good piece of work, the implementation of the RESTful interface is not exactly what I had in mind though. Also of issue, the API and the tool are currently married. This is primarily why the Blogger API is ineffective it reflects to simple functionality of Blogger and was not designed with other tools in mind. I'd suggest that the scope of the API not be limited to blogging tools. This API could perhaps be added to a Wiki tool or other like tool.
If this API where to have a life away from Joe's tool, the language current in the APIs description would need to reflect the different implementations behind the tool. For instance when POSTing a weblog entry, the current interface documentation reads "Creates a new news item and rebuilds the index.html and index.rss files..." Not all tools need to statically generate (rebuild) pages. For example, Blosxom dynamically generates its pages. Other implementation may not want (or be able) to use the index.html or index.rss names. Another such instance is the template interfaces that assume only two templates are in use -- one for HTML and another for RSS. This of course is not the case for most other tools.
The interface should allow for processing options to be passed to the receiving system. Going back to my experience using MovableType, authors can check options for automatically convert line breaks to HTML and allowing comments or TrackBack pings. The interface would have to allow for such options to be sent and modified.
I think Joe has the right idea leveraging RSS in the interface. However, the interface needs to be more specific by setting very clear constraints and guidelines particularly when it comes to RSS 2.0. Interoperability and the reliable expectation of elements are issues without additional constraints because the RSS 2.0 format is too loose and ambiguous otherwise. The XSS Profile is an example of such an attempt. Perhaps it could offer some suggestions -- a simple core of mostly required elements augmented by modules via XML namespaces with all prior cruft depreciated.
While a good starting point, I am a bit skeptical that RSS will entirely suffice in this role. If the <description> element is being used to transport the body of a post, where would an excerpt go? The <description> element was original designed to carry an excerpt of the entry. Something like <content:encoded> could be used instead, but should an element that is core be in a module? A <body> would make sense, but there is no such tag in the RSS format. Derivating from the RSS format by introducing tags specific to the task at hand in my opinion is likely to be necessary.
I think this effort is a good idea that has been long overdue. I'm enthusiastic to see it advance. Hopefully my comments are helpful in doing so.
