Greasemonkey and the Death of API Keys
I went to bed last night with a glow of satisfaction, having been received numerous plaudits for TechnoProxy, several generous contributions to the graphic design (which evolved rapidly from ridiculous to sublime) and even a link from Boing Boing. I woke up at 8:30am CEST to several angry comments, posted during the night, from people who couldn’t get the script to work. I tried it myself and, sure enough, Stef’s web service was returning empty documents for sites that I knew had Technorati links.
I figured that his API key had run out of juice, and sure enough, after showering and getting dressed I tried again (at 9:10am or so) and the script was working fine. I assume that Technorati runs on California time and resets the keys at midnight — 9am here in Prague.
This mirrored a recent discussion on the Greasemonkey list about the new Google Maps API and their wacky access system, which requires that you request an API key for a specific domain. It’s so specific that a key for www.foo.com apparently won’t work for plain old foo.com. This has caused no end of grief for normal server-side web programmers and it’s obviously uncool for client-side scripters who might be riffing off any given domain at any given time.
These two incidents confirm what I already believed: the API key system is broken and has become one of the primary hindrances to a more structured XML-based web. Back when the system was invented (by Amazon?) there was no Greasemonkey and very little client-side coding in general. So it probably seemed like a good idea to throttle the user’s requests by identifying the programmer, since in a web application environment they tended to be one and the same. With Greasemonkey, the programmer is very likely not to be the user. What’s more, if you do want to use an API key in a script you have to release it to the world, which explains why TechnoProxy has to go through Stef’s web service instead of communicating directly with the Technorati server.
The solution is to handle XML requests in the same way as HTML requests. With AJAX it’s just as easy to bring a site to its knees by pounding it with HTML requests, so it’s hard to see the justification for treating the two differently. If someone is overwhelming a server with XML requests, it should return 503 (Service Not Available) and lock the client out for some time period. This is the approach taken by del.icio.us, for example. So here’s hoping that the API key suffers a rapid demise. It can’t come soon enough for my taste if client-side coding is to reach its huge potential.
3 Comments »
Trackback URL RSS feed for comments on this post. TrackBack URI
Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
Couldn’t you let the API key be a variable that is passed to the script so that people can use their own key?
Comment by Mark J — 7/8/2005 @ 9:54 am
Funny, Aaron Boodman said the same thing. I commented on his blog, although I haven’t gotten around to posting about it to the GM list yet (deadline pressure here in AllPeers land).
Comment by Matt — 7/13/2005 @ 5:34 pm
[…] y in the source code they require it (the gm script) to query a proxy on their server (see Greasemonkey and the Death of API Keys), which does resolve the s […]
Pingback by False Positives » Blog Archive » Illuminating the Web, with GreaseMonkey — 8/17/2005 @ 7:43 pm