 |
 |
> A key (haha) thing that keys also provide is an opportunity > to have a conversation with the user of your api: who are they, > how could you get in touch with them, what are they doing with > the API, what would they like to do with the API, what doesn’t > work? These questions are difficult to ask if they are just a > IP address in your access log. -- True, but, again, there are other ways to go about this. I've baulked at doing just this in the past because it reveals the raw and primary purpose behind an API key: to track individual user usage/access. I would feel a little awkward writing (and receiving, incidentally) a message that began: -------------- Hello, I saw you using our service. What are you doing with our data? Cordially, Data service team ----------- And, if you cringe a little at the ramifications of the above, then why do you need user-specific granularity? (That's really not meant to be a rhetorical question - I would genuinely be interested in whether my notions of "open" and "free" are outmoded and based too much in a theoretical purity that unnecessary tracking is a violation of privacy). Unless the API key exists to control specific, user-level access precisely because this is a facet of the underlying service, I feel somewhere in all of this the service has violated, in some way, the notion that it is "open" and/or "free," assuming it has billed itself as such. Otherwise, it's "free" and "open" as in Google or Facebook. All that said, I think a data service can smooth things over greatly by not insisting on a developer signing a EULA (which is essentially what happens when one requests an API key) before even trying the service or desiring the most basic of data access. There are middle ground solutions. Yours, Kevin On 12/02/2013 12:57 PM, Edward Summers wrote: > On Dec 3, 2013, at 4:18 AM, Ross Singer <[log in to unmask]> wrote: >> I'm not going to defend API keys, but not all APIs are open or free. You >> need to have *some* way to track usage. > > A key (haha) thing that keys also provide is an opportunity to have a conversation with the user of your api: who are they, how could you get in touch with them, what are they doing with the API, what would they like to do with the API, what doesn’t work? These questions are difficult to ask if they are just a IP address in your access log. > > //Ed >