Google kills weather API - apps go down(lifehacker.com.au)
lifehacker.com.au
Google kills weather API - apps go down
http://www.lifehacker.com.au/2012/08/google-silently-kills-popular-api-breaks-weather-apps-everywhere/
9 コメント
My fault for lack of due diligence, but I was using it through the python-weather-api package and I had no idea it was undocumented.
You're right that using it was always a risk, and as the article says, Google were completely within their right to shut it down without any warning.
However, wouldn't it have served them better from a PR point of view to give a warning, even if only a week in advance? If all these people have been using it for so long, another week of bandwidth/etc. isn't exactly going to break the bank, and it would have been the nice thing to do, to come out and say "hey, you weren't meant to be doing this, but we'll be helpful and give you a heads up to give you time to move off it".
However, wouldn't it have served them better from a PR point of view to give a warning, even if only a week in advance? If all these people have been using it for so long, another week of bandwidth/etc. isn't exactly going to break the bank, and it would have been the nice thing to do, to come out and say "hey, you weren't meant to be doing this, but we'll be helpful and give you a heads up to give you time to move off it".
It's funny, they did give a warning of sorts.
Around a month prior to turning everything off, they started throwing in a random 403 to requests. No reasoning - just like it was being added by them to deter use.
I noticed this and just simply put in a try/catch, which "solved" the problem. Luckily I'm not building a business on it (that'd be pretty silly) so the downtime isn't the end of the world.
Here's a Stack Overflow post from during the "warning period": http://stackoverflow.com/questions/11878143/google-weather-a...
Seems like it was their way of giving us a heads up.
Around a month prior to turning everything off, they started throwing in a random 403 to requests. No reasoning - just like it was being added by them to deter use.
I noticed this and just simply put in a try/catch, which "solved" the problem. Luckily I'm not building a business on it (that'd be pretty silly) so the downtime isn't the end of the world.
Here's a Stack Overflow post from during the "warning period": http://stackoverflow.com/questions/11878143/google-weather-a...
Seems like it was their way of giving us a heads up.
The 403s probably were Google already shutting down the system. They have many servers performing the same functions; propagating a new version of the server software (in this case, an update with the weather API stripped) can take days, and in the mean time, it's luck of the draw whether you're on an old functioning server, or a new 403-spitting one. This is entirely by design: this way, if there's something wrong with an update, it doesn't immediately affect everyone, and they can hotfix things before it runs on all servers.
Try the YR API instead: http://api.yr.no/weatherapi/documentation
I have a similar weather service. All this week I am getting lots of requests. Thank you Google!
And if you want to get more infofmation about free weather and forecast mapping service, and API welcome to
http://openweathermap.org/wiki/Main_Page
I wrote about this some years ago.
Since Google’s Weather API is completely officially undocumented it’s worth noting that in future it may be wise to use Yahoo’s weather API, which is fully and officially documented.
Your post was one that popped up on my google search for more information.
Awesome.
Awesome.
When I was looking into using it there were articles talking about this being phased our sooner or later. I started using Wunderground/YQL as a backup source at that point.
Sometimes reading/researching pays dividends.
Sometimes reading/researching pays dividends.
Aha! I was wondering about that. I have something that uses it, albeit not for the most important part of the site/page: http://www.meteo-veneto.net (completely useless for those who don't live in the Veneto region of Italy), and I figured that was the problem, but was not sure. Thanks for posting this.
Not that big a deal, and I knew it was undocumented, so I guess I'll just go find another one. Recommendations? Needs to be accessible via Javascript.
Not that big a deal, and I knew it was undocumented, so I guess I'll just go find another one. Recommendations? Needs to be accessible via Javascript.
FWIW, the iGoogle API started getting flaky a couple weeks ago, intermittently returning error responses. So there was a little bit of warning.
A couple of other (supported) weather API alternatives.
* http://www.worldweatheronline.com/free-weather-feed.aspx -- free with attribution, paid option to remove attribution. (We ended up going with this for our site.)
* http://www.wunderground.com/weather/api/d/docs -- free at developer usage levels, free allowance for sending traffic to their site, can get kind of pricey if you use it a lot and weather isn't central to what you do.
Incidentally, either of these will deliver a lot more weather data than you were getting with iGoogle.
A couple of other (supported) weather API alternatives.
* http://www.worldweatheronline.com/free-weather-feed.aspx -- free with attribution, paid option to remove attribution. (We ended up going with this for our site.)
* http://www.wunderground.com/weather/api/d/docs -- free at developer usage levels, free allowance for sending traffic to their site, can get kind of pricey if you use it a lot and weather isn't central to what you do.
Incidentally, either of these will deliver a lot more weather data than you were getting with iGoogle.
I am not sure it is correct to call a private undocumented API an "API". Just because you can access it over http or whatnot doesn't mean that it is an API for you to use.
The same would hold true for any website I make that has an internal API it uses to serve up pages. Sure, you can make a service that mimics the correct calls and gets the data, but don't be surprised when I change my routes around and your stuff stops working.
The same would hold true for any website I make that has an internal API it uses to serve up pages. Sure, you can make a service that mimics the correct calls and gets the data, but don't be surprised when I change my routes around and your stuff stops working.
That's the difference between public and private, not API and not-API.
Devs using it should replace it with AccuWeather's API's. I've always liked AccuWeather's forecasts. They seemed, well, acurrate.
It was a private undocumentated API used internally. Using it was always a big risk.