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
--
Edward O'Connor
ted(a)evdb.com
Ense petit placidam sub libertate quietem.