Today, I got an email from Eddie Babcock from the Y! Geo team informing me that this was due to a regression and that they will be issuing a fix today that will revert the API to its original state.
Looking on the yws-geo forums, I saw that Eddie had posted a longer reply to my forum post, in which he states:
We apologize for introducing a regression bug in our JSON response for the places collection and causing a disruption of your application. The place elements should be part of the place array and not part of the places associative array.
The proper way to access a place in a collection is using
result['places']['place'][i].We will fix this bug in the next release of the API. Since the bug fix will restore the original behavior, it will also break your client-side fix. We suggest that you first look for a place array in the JSON response, and if one is not returned, then use your client-side fix to find the place elements.
I'm also happy to hear that they will henceforth be posting release notes on the Yahoo GeoPlanet API documentation and informing developers of updates on the forums.
I've already implemented the conditional check for the 'place' key in the result so the site should hopefully not suffer any more downtime when they switch the API back.
As they say, regression happens! Thanks for fixing this, guys, and for keeping us in the loop.
Update: Sorry, everyone, the update _did_ break the site again (just fixed it) because another method changed behavior. A call with /belongtos('Time Zone')?format=json used to return just a places array with string indices. After the update which reverted query call return values, belongsto return values also changed. This is actually a good change as it means that the API is now consistent in what it returns but, again, I would have appreciated a heads up.
Recent Comments