REST purity
Take three parameters. Encode and marshall them up as a request. Get a response. Decode. That's the basics. Do it one way and you get some people to rally up the need to gather together a fellowship of like-minded Hobbits, Dwarves, Elves and men and go on a quest to educate the world about the limitations of SOAP-RPC interfaces.
Do the exactly same thing from Amazon.com (note the rampant use of method="post" in that page), and nobody complains. Even though all of the requests do little more than request information.
From an architectural point of view, the technorati API is a RPC. Pure and simple. It follows the time honored patterns of CGI, but as Roy Fielding himself said If we thought that sucky CGI scripts were the basis for good Web architectures, then we wouldn't have needed a Gateway Interface to implement them.
When Tim Bray talks about admonishing people, I have to wonder if he took the time to reread that link before posting. It talks about three benefits to URI's in section 2. How many of the three apply to the dynamically created URI based on the request parameter scenario that we are talking about here?
Ponder specifically how the key is handled. Does this truly help to identify a new set of resources, or are we merely passing an argument to a remote procedure here?
Now let's get a bit more esoteric. The same article that Tim points to says that GET should only be used for safe interactions. In the HTTP protocol, this is refered to as idempotent. Is this request, containing a key, idempotent? The expressed purpose of the key is to ensure that the request follows the terms and conditions of the use of the API. Call it enough times in a short enough period of time, and the response changes.
Shining example of pure REST? I think not.