It’s just data

Unification: REST, SOAP, RSS, Blogger

Joe GregorioThere is a lot of discussion on the proposed Blogger API Version 2.0 and Ben brings up some very good points. This gives me a chance to trumpet REST in general and RESTLog specifically in how they solve these problems.

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 ignored... the one exception is if some XML element contains a mustUnderstand attribute with a value of "1", then you return an appropriate SOAPFault.

I'm not suggesting that such an envelope be required, or that any other changes be made to the API.  Merely that it be tolerated if it were present.

I can donate the Python server code for generating a SOAPFault message.


Timothy AppnelIf you havn't seen it, Joe's prototype and RESTful API can be found here.  A RESTful API for updating weblogs is a good idea. 

Overall, I'm positive on the notion of a Well Formed Web... though I would actually rather see a Valid Web.  The ability to automatically discover and generate dynamic or static proxies is a powerful notion.  One that need not necessarily require that all methods are POSTs or that actions be embedded inside the data.

Designing for recombinant growth

No sooner had I finished up my previous blog entry did I see this one. Jon Udell certainly has a sense of timing.

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..