Content
I apologize for the second update in as many days on the new project, but I wanted to share.
Also, please ignore just about everything in part 17. Most of the URLs are already obsolete.
The first thing to see in Spring 0.2 is the API documentation. This is being generated on the fly based on the actual dispatcher used to process the requests. View the real-time API here:
http://www.unto.net/spring/api/
(I wish I had done this for past projects — having the documentation for a web services API autogenerated is fantastic. I’ll be sure to carry this over to Essex.)
Spring 0.2 now supports OpenSearch queries for Amazon, Yahoo, and Google via their web services. Of the three, Yahoo’s web services are probably the easiest to work with. The Yahoo API is both HTTP GET-based and internally consistent. Amazon’s is GET-based, but has a long way to go before being internally consistent. Google’s is SOAP-based, which is probably more complicated than it needs to be. All three services return results in XML format. Spring translates those results into OpenSearch RSS with XSLT stylesheets. You can view the OpenSearch stylesheets for Google, Yahoo, and Amazon. (You’ll need to read some code to see how Spring fetches the results.)
Feel free to try out an Spring OpenSearch query or two:
AJAX on Yahoo
AJAX on Google
AJAX on Amazon
Each of those searches (or ones that you may actually want to use) can be saved in a blogreader. I.e., they are RSS feeds.
I will undoubtably add more OpenSearch engines over time. However, I am limited on the number of queries I can make a day to each service. In particular, if you save Google searches, please use your own Google Web ID, like this:
http://www.unto.net/spring/google/web/opensearch/ajax?GoogleWebId=[your Google Web ID]
Up next, Spring 0.3 — all of this, tied together with a fancy client-side user-interface.
July 6th, 2005 at 11:54 am
I just read a piece called Greasemonkey and the Death of API Keys that rings very, very true. It talks about how API keys, such as Google’s or Amazon’s web services API keys may have made sense in an age in which the server (i.e., my server) was the client. But in an age of Greasemonkey, the end user client may actually want to perform the requests.
The author is absolutely right, though he does miss the point that this has been the problem all along — long before Greasemonkey. Greasemonkey scripts are one more way for client-side applications to make web services calls. But they are hardly the only way. Any AJAX-ish XMLHttpRequest could be making a web services call and need an API key.
And where does that key come from? In the case of Spring, it comes from unto.net. (Unless you are generous enough to provide your own for that request.) Of course, my 1000 requests will run out in no time and then we’re done for the day.
So do I hear a rousing cheer for the end of Web API keys? Who is with me?
July 6th, 2005 at 7:42 pm
How to account for per-request fees without some kind of key? If I am to provide a web service that is charged on a per request basis, for example, I need a way to keep track of how many requests come from a particular customer (be that customer another “server” or the end-user client itself). Client IP is not good enough.
July 6th, 2005 at 7:48 pm
I agree that client IP isn’t good enough, but neither really is a web API key when you have to distribute that API key to clients everywhere. Web API keys work well when you have one trusted client talking to your server. Not so much in Web 2.0.
Yahoo is using a “application ID.” This is a little different in that it isn’t used to meter (IP addresses are), but rather to just help you keep track of where your users are.
Perhaps some sort of OpenID scheme would work? You could then ask the end-user to authenticate and send a token to the server per-request. That token could be tied to the application ID as well… Of course this all leads to a micro-payment model. Someday?