Yahoo does Google four better on XML search APIs

While I track trends in the Web services space, I have to admit that I'm normally not a follower at the API level as this or that company opens up its systems to public developer access. When I saw today's news that Yahoo's Jerry Yang was going to announce that Yahoo is embracing Web services by offering up APIs to its search engine, my first reaction was to yawn. But upon further inspection, Yahoo's announcement is pretty interesting.
Although it still refers to the effort as a beta program, Google has been doing this for over two years. For example, if you check out my Transparency Channel, you can see on the lower right-hand side were I have pre-executed a Google search on "media transparency" and included a results box (Google-branded, of course) right on the page. Radio Userland, the blogging solution that I'm testing for review (using my Transparency Channel as the guinea pig) comes with pre-built macros for accessing Google's search APIs via a Web services interface. All you have to do is get a license key from Google (a relatively simple process that requires getting a user ID on Google's systems) and live with the limitation of 1,000 search executions per day. Google has some pretty tight licensing terms. For example, you can't build a commercial service off the company's APIs without asking first (according to the company's FAQ).
The Yahoo APIs appear to work slightly differently.

Instead of keying on a per developer license key, Yahoo works with an application ID. This is probably because one developer can have multiple applications and Yahoo would prefer to track that than the number of unique developers. Something else that's cool about the Yahoo program is how, compared to Google's APIs which are limited to a single type of search, Yahoo's are structured into five services: image search, video search, local search, web search, and news search.
Like Google, Yahoo has a limit on the number of queries that can be executed--but it's 5,000 queries per IP address per 24-hour period for all but the local search service, whose limit is 1,000. That limit is understandable when you think of how difficult it would be for Yahoo to keep track of budding local "search economies" that could cannibalize Yahoo's business if too many people got into the game. Yahoo also has an explanation that points out how people with dynamic IP addresses could prematurely run into a query limit if the IP address of their Web server changes to one that was previously in use by someone else who was also taking advantage of Yahoo's APIs.
Just for kicks, I'm interested in using the APIs as a part of my Radio Userland experiment. But to do so, I must write an Yahoo XML query widget using UserTalk (the scripting language behind Radio and Userland's other products) or wait for someone else to publish one on the Web. If Yahoo is smart about it, the folks who are working on the APIs will also release canned widgets and example code for some of the more popular "consumer" development environments like UserTalk and even the higher end ones like Visual Studio .Net, Java, Perl and Python. Lack of examples like this in the documentation of operating sytems and developer solutions is one of my biggest pet peeves. At least one company -- eBay -- comes close to getting it right by providing downloadable code for 14 separate app dev environments including 4D and Flash. Speaking of Python, it didn't take long for at least one Python developer to pick up on a blog post about the APIs by Yahoo's Jeremy Zawodny and write some code.
It's fun to watch how the really big dot-coms like Yahoo, Google, and eBay are establishing programs that exemplify the benefit of Web services. The more this happens in the big dot-com space, the more we'll see Web services get wrapped into all facets of computing, which in turn will empower IT buyers with a lot of leverage over their suppliers of both hardware and software. That's because any system, regardless of what's under the hood, can pitch and/or catch XML and Web service requests. (We don't have to know whether Yahoo is running Windows, Linux, Unix or an IBM mainframe, for that matter.) Success will go to the solution providers that have the best support for Web services standards, that do the best job of speeding access to and development of Web services (be it for server-to-server or user-to-server communications), and that do the best job on reliability, security, and performance. (To the extent that Web services are part of a transactional chain, they can't go down, be vulnerable to trespassers, or respond with the equivalent of an hour glass.)
What will be interesting to watch is how commerce gets wrapped into the equation. Instead of having to contact these companies to execute commercial licenses or exceed certain limitations, just build the commerce capability into the APIs. For example, at the moment, I'm about to exceed a query execution limit. Can't the code include a way to pay for more?