...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.
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.
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.
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.
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.
(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.
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.
at
Unification: REST, SOAP, RSS, Blogger
Joe Gregorio: Seed planting time. What if RESTLogImpl.py 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]