iBLOGthere4iM
<< Previous Main Next >>

Here's the WSDL, C# and an abstract implementation w/ documentation for PaSSAPI. This is a Request For Comments in order to first introduce and receive feedback for making this a great API.

Where did PaSSAPI come from?
PaSSAPI started as an idea of Dave Winer, which I stole from him when he didn't pursue further. Dave introduced the idea of Portable and Simple Syndication, which would allow RSS 2.0 element to be used w/in other XML grammars. Originally, Dave called the format PSS. I renamed it PaSS and released version 1.1 last December. PaSSAPI is an API built on top of PaSS.

How did I develop PaSSAPI?
PaSSAPI was developed entirely by writing a WSDL file that described the methods of MetaWeblogAPI and BloggerAPI. The first implementation is entirely in SOAP, but I plan to release an HTTP GET and HTTP POST version in the near future. I may also add methods and welcome suggestions.

Why not just use MetaWeblogAPI?
MetaWeblogAPI uses a great Web RPC called XML-RPC. Unfortunately, I wanted a protocol that worked equally w/ SOAP, HTTP GET and HTTP POST. By allowing use of SOAP, you can actually send PaSSAPI request over alternate transports like SMTP. XML-RPC is bound to HTTP. Also, XML-RPC method calls cannot be expressed in WSDL and I'm pretty upset at Microsoft and IBM for this failure.

Why not just use AtomAPI?
AtomAPI uses another great Web RPC called REST. Unfortunately, REST like XML-RPC is bound to HTTP and cannot be expressed in WSDL.

Is PaSSAPI competitive to AtomAPI?
Not really. I didn't take the time to incorporate the ideals of Atom into PaSSAPI. If you want to use REST and Atom syntax, then I suggest you continue to use AtomAPI, but if you want a lightweight protocol that works out of the box w/ existing tools, then you might want to consider PaSSAPI.

What do you mean by Works Out-Of-Box?
Any tool that sucks in WSDL can be made to work w/ PaSSAPI in minutes. Trying to do the same in WSDL incompatible technologies takes man-days, if not man-months of effort and is generally bug laden.

What do you mean by lightweight protocol?
By lightweight, I mean that the entire protocol is described in a 400 line XML file and requires very little code to implement.

What is down the road?
First, iM going to listen to the feedback, then I plan on incorporating some of the feedback into the API and finally I will start releasing tools, like C# and Java client and server interfaces.