It’s just data

The only thing constant is...

...change.  Blogger API 2.0.  Sigh.  It looks like the future of blogging clients and servers is to have more code in if/switch/case statements and configuration options than actual logic.  What's worse is a future where - despite all the interfaces being "open" - the only real guarantee you will have is that vendor A's clients will work with vendor A's servers.  That's called vendor lock-in.

At the time the MetaWeblog APIs were written, I wrote this.  Deja vu all over again.

IMHO, the right thing to do is to focus on the bits and bytes that go across the wire.  Define an XML message for each interaction.  In fact, divide the XML message into two parts - a header which contains "login" information, and a body which contains "post" information.  Allow tool specific extensions through namespaces to support "filters", "actions", etc..

I feel the same way about RSS. Four versions later and I don't feel like coding for anything else but the base "Title, Description, Link" even that is getting to be a mess. It seems like everything else is a moving target.

Posted by Colin Faulkingham at

The difference is that if you code to the base "title, description, link", it will still work four versions from now. People will still understand your RSS, no matter how many other extensions are invented, forgotten, and rediscovered between now and then.

Posted by Sam Ruby at

Sam, I suspect the same is true of the Blogger API. There's a lot of background to this, notably that their server has been offline so much this year that the installed base among their users is very very small, where the users of Manila, Moveable Type and Radio have been getting steady service. All three of those support the MetaWeblog API. We've even tested the "working together" thing, I asked for a feature from Ben in their MetaWeblog API implementation, and they did it. No fuss no muss, and no breakage. That Pyra doesn't want to work cooperatively is a strategic decision for them that may or may not work. I think the MetaWeblog API (and RSS 2.0) will continue to work for many years to come, and the API may even be extended, in a continuous fashion. But this is a very fluid time, so we can't really say for sure what happens next. Lots of back-channel conversations.

Posted by Dave Winer at

I have no comment at this time. But I reserve the right to say a generally-tagetted "I told you so!" at some point in the future. 8-)

Posted by Mark Baker at

Mark, if you diff BAPI 1.0 and BAPI 2.0, you will note that it is not the verbs that changed, but the nouns.

Posted by Sam Ruby at

Right, but the nouns are part of the interface, so the interface changed.

Posted by Mark Baker at

Maybe it's just my poor hearing, but it sure sounds like you guys want REST.

Posted by Aaron Swartz at

Mark, Aaron, I guess if all you have is a hammer, then every problem looks like a nail.

Had this been a fully REST compliant implementation, this change would not have affected the methods used, but would have affected the representation (the "Re" in REST) of the data.

Of course this part of the interface constitute "an exercise left for the student" in the REST architecture.

Posted by Sam Ruby at

And sometimes you had a nail all along, and you didn't realize it.

You said it yourself above re RSS;

'The difference is that if you code to the base "title, description, link", it will still work four versions from now.'

Posted by Mark Baker at

Every valid HTML 1.0 page is a valid XHTML 2.0 page? I think not.

REST does not prevent a mix of incompatible DOCTYPES and schema from existing. I can only presume that most browsers have to deal with this with a variety of if/case/switch logic, and/or by dropping support for prior proprietary extensions.

That being said, HTML is better designed from an evolvability point of view than most existing XML RPC interfaces. That isn't to say that one can't design evolvable XML RPC interfaces. In fact, both the MetaWeblog and proposed Blogger 2.0 APIs are a noticable improvement over Blogger's 1.0 API.

In so doing, they attain approximately the same level of evolvability as SOAP RPC/Enc does, but not quite the same level as SOAP DOC/Lit (or either RSS 1.0 or RSS 2.0) can.

Posted by Sam Ruby at

(This seems like as good a place then any to bring this up.)

On the topic of REST, Joe Gregorio and I have been discussing such an API and its merits/appropriateness mostly through private email. Joe has developed a prototype with the beginnings of a working RESTful API.

I've been disappointed that a great deal of its rich feature set is not (and cannot) be exposed through Blogger or MetaWeblog APIs. Joe has similar observations though he is not a MovableType user. I thinking an interface utilizing REST and other related theories may provide a more flexible and scalable mechanism.

Rather then debate amongst ourselves, we opened a mailing list on Yahoo for discussing these issues out in the open as a community -- in one place. ;)

Even if nothing becomes of this notion of a RESTful API for publishing, I think its important that the conversation be had. All are welcomed and encouraged to participate. And please spread the word as I've been rather preoccupied and have not done a proper job of it yet.

Posted by Timothy Appnel


If you havn't seen it, Joe's prototype and RESTful API can be found here:

Posted by Timothy Appnel


Well, RDF would have taken care of the format part in an extensible way.

Posted by Aaron Swartz at

Yes, but sadly RDF serialization in XML was not developed for mere mortals.

Posted by Timothy Appnel at

I have posted a rather lengthy response

Posted by joe


RESTful API needed. Apply within.

With the recent unveiling of the Blogger 2 API there has been a great deal of discussion regarding its shortcomings and best route going forward. I've come to the conclusion, it seems if ever there was a tool/medium that needed a RESTful API it's weblogging.... [more]

Trackback from tima thinking outloud.


Unification: REST, SOAP, RSS, Blogger

Joe Gregorio: Seed planting time. What if allowed for the posibility that <item> elements it receives using an HTTP PUT may be enclosed in Envelope and Body elements, as described here. All I am asking is that these be ignor... [more]

Trackback from Sam Ruby


Add your comment