|Extensible Weblog API|
This is a collection of some initial ideas for a new Weblog API meant to replace the Blogger API. The Blogger API was designed to specifically meet the needs of the original Blogger service. Because of this, it has some major limitations which this proposal tries to overcome. Some of the ideas covered here come from Dave Winer's MetaWeblog API and the discussion that followed it, and this posting by Evan Williams. I've added some of my own ideas on top of that.
The main purpose of the API described here is to enable remote content editing. The functional scope is similar to that of the current Blogger API, but (at least for now) I'm leaving away non-content related stuff like template management.
I'm writing this with XML-RPC in mind and make heavy use of XML-RPC terminology, but there should be no reason why it couldn't be implemented with SOAP or some other protocol.
This first sketch also leaves out all the important details. The purpose is to describe the basic framework of the API.
Basic Design Principles
Maybe the most important design idea in this proposal is the use of structs for some central types of parameters. The main advantage compared to fixed parameter lists is that it allows for an interface that is concise and clear and at the same time extensible and able to evolve. Clients and servers can and should ignore the struct members they don't understand. This allows us to accomodate applications with sightly different feature sets, and it also gives us a way to evolve the API over time in a compatible manner by adding new struct members if needed.
It is also possible that individual applications choose to extend specific struct types by adding members not defined in the spec. For this, I propose a scheme similar to that used in the MIME format in that non-standard struct members must have a name starting with "x-", e.g. "x-someMetaInfo". Over time, non-standard struct members can be included into the standard, resulting in the "x-" prefix to be dropped.
The headers struct
The headers struct is sent as the first argument in every client request. It holds meta-data about the call, including the protocol version being used, authentication info and information about the client software. I leave it up for discussion whether authentication should be done by sending username and password for each request, sending a session cookie obtained from the server when logging in, or using HTTP authentication.
Client software recognition is done through appName and appVersion members in the headers struct. My guess is that this would basically do the same for Blogger as appKeys do now, and it would remove the overhead for both Pyra and client developers of handling appKeys. Additionally, clients would be recognizable to other services than Blogger. But of course it would be up to Pyra to decide if appKey was still required for Blogger as an x-appKey member in the headers struct.
The post struct
Another recurring data type in this proposal is the post struct, which holds the various parts that make a weblog post or story. What exactly the standard members of posts should be is open to discussion. I propose the following:
So finally, here come the methods:
That's it for a first rough sketch. Please let me know what you think!
michelv, 3/18/02 1:00 PM
Or you could also help there
There we discuss a common Weblog API. The current choice seems to be Wasabii (wasabii.org).
hns, 3/18/02 2:12 PM
Thanks for the link
I know wasabii but I'm not a big fan of it. It tries to be the ultimate weblog API, but IMHO it comes out complex, rigid and not very elegant. For example, who is going to use the method to get a range of comments? Who is going to implement it? What exactly is a space, what's a cloud?
Which is why I decided to write down my own. I think if you compare my pre-spec with the Wasabii one, you can see the two are hard to reconcile.
I'll send a link to this site to the weblog-devel list, though.
PS: regarding my remark on retrieving comments above: I have no problem with comments being treated as first class content, or websites where the line between top-level postings and comments is blurry. But I think in that case it's the job of the server to serve the comments as "posts" via remote API instead of basically duplicating the whole story related functionality for comments.
yhvhbfqR836, 7/6/14 4:31 AM
online for 5964 Days
last updated: 7/6/14 4:31 AM
Youre not logged in ... Login