+1 to the change - having a simple place to discover the current api capabilities will make client work a lot easier.
On Thu, Dec 18, 2008 at 12:31 PM, Evan Prodromou <[email protected]> wrote: > So, we've had a problem with Identi.ca today. We upgraded to use the "new" > validation method in the Twitter API, but clients like Twhirl were using the > "old" method. > > For a monolithic system like Twitter, this is no biggie. For Laconica, we > need to support a spectrum of versions across hundreds of sites. So, I think > we need a reliable way for clients to get an accurate idea of what the API > is going to do. In particular, as we start implementing features that > Twitter doesn't have (like file sharing, groups, and so on), we'll want a > way for API clients to discover them. > > I propose that we add the following three extensions to the Twitter API. > > <api-root>/laconica/version.<format> > > This would return the LACONICA_VERSION constant. It would be a very coarse > way for client software to adapt to the server's API. The client developer > would have to know that versions of Laconica < 0.6.4 don't support the > 'since' parameter (say), and ones after 0.8.x support multimedia sharing (or > whatever). > > <api-root>/laconica/config.<format> > > This would be a subset of the values in the $config variable (ones that > don't expose secure information like passwords!). API clients could use this > to determine valuable info such as the site name, whether XMPP is enabled, > what the XMPP bot address is, and so on. > > <api-root>/laconica/wadl.xml > > This would give a full Web Applications Description Language (WADL) > description of the API provided by this instance -- which API methods are > supported, what arguments they expect, and what data they return. There's > already a half-decent WADL description for the Twitter API that the Netbeans > folks did, so we could build on that. > > I briefly considered putting these methods under the /help/ path, since it > makes sense there, or under /extensions/, which might be useful for other > third-party service implementers. But to avoid future name clashes with > Twitter, I think we can only be sure that they're not going to make a > "laconica" path in their API. > > Comments, ideas, questions, objections? > > -Evan > > > _______________________________________________ > Laconica-dev mailing list > [email protected] > http://mail.laconi.ca/mailman/listinfo/laconica-dev > > -- --- Bear [email protected] (work) [email protected] (jabber & email) http://code-bear.com/bearlog (weblog) PGP Fingerprint = 9996 719F 973D B11B E111 D770 9331 E822 40B3 CD29 _______________________________________________ Laconica-dev mailing list [email protected] http://mail.laconi.ca/mailman/listinfo/laconica-dev
