Hi everybody,
Jimmy wrote:
I have been thinking a little bit as well about a model with full blown keys (like the Google API) -- the point could be that for free software, we can give out free keys and support those users at our own expense. But for proprietary software, we can charge money for the keys.
Brion Vibber wrote:
For server-side systems (mirrors and other sites including our bits) something like the Google API's keys would work ok. A relatively small number of server admins will be setting things up, and the keys will be 'secret', kept on that server.
Things are a bit different with the client-side software integration envisioned by the KDE folks; like a web browser these apps will be distributed to thousands of users and should "just work". A per-user key setup would probably not be acceptable, while a non-secret key distributed with the app (like a user-agent string) can be easily ripped and faked by someone less scrupulous.
We probably want client-side apps to be able to act like a browser (easy, no manual setup), while trying to avoid server abuse by someone who decides to snarf a million pages a day; a per-IP rate limit on the 'free software key' is probably sufficient to automatically curb server-side abuse.
At work we've recently been over a lot of these same issues while developing our API[0]. We've gone with a scheme which utilizes per-application tokens. For tasks which require a user account, there are per-user-per-app tokens. You can read more about it here[1]. Flickr recently drafted their new auth API (here[2]) which (I think) has a similar scheme.
Anyway, I thought looking at existing APIs which try to handle some of the same use cases as a hypothetical Wikipedia API might be helpful.
Ted
0. http://api.evdb.com/ 1. http://api.evdb.com/docs/auth/ 2. http://flickr.com/services/api/auth.spec.html