9

I decided to pull information from Google's Weather API - The code I'm using below works fine.

            XmlDocument widge = new XmlDocument();
            widge.Load("https://www.google.com/ig/api?weather=Brisbane/dET7zIp38kGFSFJeOpWUZS3-");
            var weathlist = widge.GetElementsByTagName("current_conditions");
            foreach (XmlNode node in weathlist)
            {

                City.Text = ("Brisbane");
                CurCond.Text = (node.SelectSingleNode("condition").Attributes["data"].Value);
                Wimage.ImageUrl = ("http://www.google.com/" + node.SelectSingleNode("icon").Attributes["data"].Value);
                Temp.Text = (node.SelectSingleNode("temp_c").Attributes["data"].Value + "°C");
        }
     }

As I said, I am able to pull the required data from the XML file and display it, however if the page is refreshed or a current session is still active, I receive the following error:

WebException was unhandled by user code - The remote server returned an error: 403 Forbidden Exception.

I'm wondering whether this could be to do with some kind of access limitation put on access to that particular XML file?

Further research and adaptation of suggestions

As stated below, this is by no means best practice, but I've included the catch I now use for the exception. I run this code on Page_Load so I just do a post-back to the page. I haven't noticed any problems since. Performance wise I'm not overly concerned - I haven't noticed any increase in load time and this solution is temporary due to the fact this is all for testing purposes. I'm still in the process of using Yahoo's Weather API.

        try
        {
            XmlDocument widge = new XmlDocument();
            widge.Load("https://www.google.com/ig/api?weather=Brisbane/dET7zIp38kGFSFJeOpWUZS3-");
            var list2 = widge.GetElementsByTagName("current_conditions");
            foreach (XmlNode node in list2)
            {

                City.Text = ("Brisbane");
                CurCond.Text = (node.SelectSingleNode("condition").Attributes["data"].Value);
                Wimage.ImageUrl = ("http://www.google.com/" + node.SelectSingleNode("icon").Attributes["data"].Value);
                Temp.Text = (node.SelectSingleNode("temp_c").Attributes["data"].Value + "°C");

            }
        }
        catch (WebException exp)
        {
            if (exp.Status == WebExceptionStatus.ProtocolError &&
                exp.Response != null)
            {
                var webres = (HttpWebResponse)exp.Response;
                if (webres.StatusCode == HttpStatusCode.Forbidden)
                {
                    Response.Redirect(ithwidgedev.aspx);
                }

            }
        }

Google article illustrating API error handling

Google API Handle Errors

Thanks to:

https://stackoverflow.com/a/12011819/1302173 (Catch 403 and recall)

https://stackoverflow.com/a/11883388/1302173 (Error Handling and General Google API info)

https://stackoverflow.com/a/12000806/1302173 (Response Handling/json caching - Future plans)

Alternative

I found this great open source alternative recently

OpenWeatherMap - Free weather data and forecast API

Community
  • 1
  • 1
mitchimus
  • 830
  • 1
  • 10
  • 24

4 Answers4

12

This is related to a change / outage of the service. See: http://status-dashboard.com/32226/47728

enter image description here

I have been using Google's Weather API for over a year to feed a phone server so that the PolyCom phones receive a weather page. It has run error free for over a year. As of August 7th 2012 there have been frequent intermittent 403 errors.

I make a hit of the service once per hour (As has always been the case) so I don't think frequency of request is the issue. More likely the intermittent nature of the 403 is related to the partial roll-out of a configuration change or a CDN change at Google.

The Google Weather API isn't really a published API. It was an internal service apparently designed for use on iGoogle so the level of support is uncertain. I tweeted googleapis yesterday and received no response.

It may be better to switch to a promoted weather API such as: WUnderground Weather or Yahoo Weather.

I have added the following 'unless defined' error handling perl code myself yesterday to cope with this but if the problem persists I will switch to a more fully supported service:

my $url = "http://www.google.com/ig/api?weather=" . $ZipCode ;

my $tpp = XML::TreePP->new();
my $tree = $tpp->parsehttp( GET => $url );

my $city = $tree->{xml_api_reply}->{weather}->{forecast_information}->{city}->{"-data"};

unless (defined($city)) {
    print "The weather service is currently unavailable. \n";
    open (MYFILE, '>/home/swarmp/public_html/status/polyweather.xhtml');
    print MYFILE qq(<?xml version="1.0" encoding="utf-8"?>\n);
    print MYFILE qq(<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "xhtml11.dtd">\n);
    print MYFILE qq(<html xmlns="http://www.w3.org/1999/xhtml">\n);
    print MYFILE qq(<head><title>Weather is Unavailable!</title></head>\n);
    print MYFILE qq(<body>\n);
    print MYFILE qq(<p>\n);
    print MYFILE qq(The weather service is currently unavailable from the data vendor.\n);
    print MYFILE qq(</p>\n);
    print MYFILE qq(</body>\n);
    print MYFILE qq(</html>\n);
    close MYFILE;
    exit(0);
}...
Abdul Rahman
  • 2,097
  • 4
  • 28
  • 36
ClearCrescendo
  • 1,145
  • 11
  • 22
  • 2
    Excellent answer! I would be pushed to speculate that the dismantling of iGoogle is affecting this service. I was vaguely aware that the API was "for widget use only" so I suppose it isn't overly surprising that there are issues with service reliability. I will look into using those alternatives and possibly adapting the ideas behind your exception handling. Thanks again! – mitchimus Aug 10 '12 at 01:05
  • 2
    Sheesh! Break out your try/catches everyone... +1 – Derek Hunziker Aug 10 '12 at 02:08
  • As of August the 27th, 2012 the service is responding with a consistent 403 error and a message indicating that you are sending automated queries.: – ClearCrescendo Aug 31 '12 at 19:23
  • 1
    I've re-implemented with Weather Underground. Example perl code for a polycom phone weather home page here: https://gist.github.com/3613378 – ClearCrescendo Sep 03 '12 at 21:31
1

That`s the same thing we found out.

Compare the request header in a bad request and a working request. The working request includes cookies. But where are they from?

Delete all your browser cookies from google. The weather api call will not work in your browser anymore. Browse to google.com and then to the weather api, it will work again.

Google checks the cookies to block multiple api calls. Getting the cookies one time before handling all weather api requests will fix the problem. The cookies will expire in one year. I assume you will restart your application more often then once a year. So that you will get a new one. Getting cookies for each request will end in the same problem: Too many different requests.

One tip: Weather does not often change, so cache the json information (for maybe a hour). That will reduce time-consuming operations as requests!

Kjartan
  • 18,591
  • 15
  • 71
  • 96
Lato
  • 11
  • 1
1

This is by no means a best practice, but I use this API heavily in some WP7 and Metro apps. I handle this by catching the exception (most of the time a 403) and simply re-calling the service inside of the catch, if there is an error on the Google end it's usually briefly and only results in 1 or 2 additional calls.

David McSpadden
  • 451
  • 4
  • 18
0

I found that If you try the request in a clean browser (like new window incognito mode on chrome) the google weather service works. Possible problem of cookies?

avillar
  • 11
  • 3
  • 3
    Unfortunately fresh browser doesn't seem to work. The issue is, the service itself was never intended to be used outside of the Weather Widget iGoogle used. Due to a number of factors, including iGoogle being slowly phased out, I'm not surprised that we are having performance issues. I will post up my code for the Yahoo API in the next day or two. But I don't think any of us are really going to see an end to the issues, regardless of browser state. – mitchimus Aug 17 '12 at 14:00