It appears to be working again today (Saturday, 3 days after the first reports). I wasn’t able to make the switch to Google’s yet, so I’ll still use Yahoo’s for now. But, there are some changes I need to make to better prepare if something like this happens again.

Yahoo rolled out some updates to their Maps API on Tuesday night, but unfortunately they broke their Geocode API in the process. I know, I know, don’t rely on free APIs, nothing like a day without new users to drive that point home. In spite of knowing I shouldn’t rely on this API, I’m troubled by the way this was broken. I would expect better from Yahoo, who put a lot of resources into their developer network.

First, they didn’t version this release, it’s still “V1”. If they had bumped the version and kept the old one around, the problem could have been avoided. Secondly, it’s essentially a schema problem which are much more difficult to code around than the service being down or throwing errors. While the response still technically passes schema validation, it’s easy to see that the data is not right. Third, it is still not fixed after they’ve known about it for over a day.

Here’s the bug. Run a zip code lookup:


this is the response:

<?xml version="1.0"?>
   <Result precision="zip">
      <City>Portland, OR  97201</City>
      <State>United States</State>
<!-- ws03.search.scd.yahoo.com compressed Thu May 17 09:55:39 PDT 2007 -->

The city, state and zip are combined into the city field while the country is put into the state field. Whoops. So the city field has to be further parsed in order to put the data in the right place. I use this service to take care of that for me, and don’t have time at the moment to do it. So, I bumped the limit on my state field in the database in order to work around this, but my geo data will be all messed up until this is fixed and then I’ll have to go back through and clean it up.

I’d argue that zip code lookups are fairly common and there should be a test case for this. Time to look at Google’s geocoder I suppose.