July 4, 2003
@ 12:58 AM
The Echo Project: Blog Posting API

A number of people seem to think that a RESTful API is the way to go with the blog editing API that is being collaboratively designed on Sam Ruby's wiki. Tim Bray has posted examples of posting, editing and deleting entries would look like on the wire using a RESTful API. The cool thing about RESTful APIs such as Joe Gregorio's CommentAPI is that there is a very low barrier to implementing them on the client or the server. No need for complex application frameworks or layers of indirection just HTTP + XML. The other thing that is interesting is that such RESTful APIs show that distributed computing doesn't have to follow the RPC paradigm but instead can be primarily seen as passing well-formed documents back and forth between entities. The final benefit of a RESTful APIs I love harping on is that one can layer web technologies on the API to solve problems like message encryption & user authentication (SSL & HTTP authentication) or specifying application IDs (cookies) instead of placing those in the message format.

The question as to whether to have a RESTful API is a no brainer. Whether there should be SOAP or XML-RPC versions of the API are now the main point of contention in Sam Ruby's blog and the wiki. Originally I was indifferent to XML-RPC and said as much in my first pass at a conceptual model for theblog editing API but on further investigation I realize I actually am downbeat about the technology. The primary problems I have with the technology are that XML-RPC doesn't support namespaces nor does it support sending elements with attributes as message payloads. This breaks the model of just sending messages containing well-formed documents around between client and server but instead starts to look like RPC. This is not the way a Web technology should work because it leads to tight coupling between clients and servers as well as makes the API less extensible.

SOAP allows you to model and implement communication between the client and the server as simple message passing where the messages are well-formed documents. However there is extensive tool support from various vendors and Open Source APIs to make it look like RPC for the folks who would prefer the simpler programming model. Another benefit of SOAP is that one can use the growing XML Web Services family of technologies to further improve the developer story. Want to know what operations a server supports? Just check its WSDL or do some negotiation using WS-Policy. Being able to programmatically determine what operations a server supports is especially important for apps like RSS Bandit which may have special BlogX specific operations (e.g. update my BlogX blogroll from my RSS Bandit feeds list) as well as using whatever standard format the Echo project comes up with to be able to talk to Blogger, SixApart and LiveJournal blogs.

Ideally since I plan to document all the non-Echo APIs I'll be implementing in BlogX, any other client or server should be able to expose this functionality as well. That's why the XML Web Services family of technologies like WSDL or WS-Policy become interesting.


BlogX and RSS Bandit updates

I've decided to give a shot at moving my K5 diary to being based on BlogX over the weekend if can finish my XML Journal opinion piece in time. If successful I'll test it out then try for a new release the following weekend. So far, there is already one significant difference I can tell between the BlogX and RSS Bandit workspaces. It seems folks on the BlogX workspace are used to checking out files for a long time and locking others out. IMHO, if you aren't a project admin (i.e. the equivalent of a committer in non-GotDotNet Workspace OSS projects) and own a certain aspect of the code base you shouldn't be holding down files for weeks at a time.

I also plan to fixup the RSS Bandit code this weekend and if Torsten and others add in some features they've been talking about in the next week or so I should be able to do another RSS Bandit release the following weekend.

So far no one has signed up for my EXSLT.NET Workspace although Hardy Erlinger sent me an email where he mentioned that some of my date/time functions were US-centric and didn't work correctly on his German machine but he fixed the issue and would like to send a patch.


Derivation by Restriction Still to be Avoided

I had lunch with Harry Pierson last week and he slowly began to realize that an XML schema does not need to model inheritence just to do validation. He also understood what I mean when I said that derivation by restriction simply cannot be modelled using traditional Object Oriented Programming concepts.

I should probably package up all these posts about derivation by restriction I've made in my diary and turn them into an article on MSDN or XML.com


Get yourself a News Aggregator and subscribe to my RSSfeed

Disclaimer: The above comments do not represent the thoughts, intentions, plans or strategies of my employer. They are solely my opinion.