Extensible Weblog API |
First sketch 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! |
online for 8316 Days
last updated: 7/6/14, 4:31 AM Youre not logged in ... Login
|