Twitter clients are fun toys, but not all that useful for me. The Google Data API, on the other hand, provides the ability to store complex calendar data in the cloud (among other things), and fits in perfectly to serve as back-end cloud storage to my application.
On the other hand, my particular application needs to be flexible enough to switch cloud providers on a moments notice, so I am unable to use the .Net client library provided by Google Code. Creating an “adapter” to connect my application model (which has its own representation of calendars and events) to the Google’s back-end is the way to go. But it can be a bit tedious at times. So, I set out to see if the WCF REST starter kit could help me out.
The HttpClient Class
The WCF Rest Starter Kit, at least from the client side perspective, uses two classes to get most of the job of consuming REST APIs done: HttpClient and HttpResponseMessage. The framework is a joy to use. Combined with the “Paste XML as Type” Visual Studio addin, and my job is becoming down right easy. Except I could not get it to work – I kept getting authorization failures (Error code 401- Unauthorized). I was sure I sent the proper authorization headers with the request.
Note: I did not use the Credentials property on the TransportSettings of the HttpClient class because it looks to me like the Google APIs use a custom header for authorization in which a token is provided that you obtain in a previous “login” request not discussed here. I am not sure if this is playing a role in this issue or not. There are other ways to “login” to Google, but I did not investigate those avenues.
Fiddler to the Rescue
With the help of Fiddler (a great application, by the way), I discovered that Google likes to respond with a redirect code “302 Found” when you access your calendar feeds, directing you to a new URI that contains a large coded string within it. I do not know why this is the case – maybe for load balancing or quality of service issues – but nevertheless the HttpClient class merrily redirects and tries to grab the new resource location (automatically, thank you very much). But it fails to send the original headers! Now, I am no HTTP protocol expert, but shouldn’t the WCF Rest toolkit send the same headers to the re-directed URI as was sent to the original URI?
The Solution
The solution is to set the MaximumAutomaticRedirections property of the TransportSettings property on the HttpClient class to zero, which results in the “302 Found” being returned to your application rather than triggering an automatic re-direct. From there you can re-issue the same Get to the new location.
Works like a charm.
[ But I wish I did not have to do all that. ]