The primary goal of our Windows Store and Windows Phone Store APIMASH Starter Kits is to pave your way toward integrating a great many diverse data sets into your own applications. To that end, the provided projects tend to focus mostly on the “happy path,’ where the expectation is that the service is up, the client connection is solid, and the data returned is in the expected format. As you move closer to publishing your application to the store, however, you’ll want to test for conditions such as an invalid API Key, a request timeout, or a service call periodically returning a 404 (Not Found) to ensure the user experience is the best it can be, and as a result, help your app enjoy higher ratings and more downloads!.
One handy addition to your tool belt in this regard, is Fiddler, and specifically its AutoResponder facility. If you’re not familiar with Fiddler, you can download it free (get the .NET 4 version for use with Windows Store apps), and use it as an HTTP proxy to intercept traffic from your application to the various services being targeted. I’ve used it for quite a while for debugging web and client applications, but only recently became acquainted with the auto-responder feature.
The premise behind the auto-responder is simple: create URI rules, and whenever a given rule is matched, instruct Fiddler to return a canned response (generally from a file) instead of carrying out the actual call.
In practice, I’ve been running my application normally (“the happy path”) capturing the traffic in the left most pane of Fiddler (below). Then I drag and drop relevant sessions from the left to the AutoResponder tab on the right. That action creates a rule that returns that same HTTP response whenever the application issues the exact same URI request.
Resending the same response for the same request isn’t all that interesting, so once you create a rule you’ll likely want to change either (or both) the rule and the action that follows that rule. To get a better view of this in action, here are a couple of “real” examples leveraging the TomTom Bing Maps API Starter Kit that I put together.
In the TomTom and BingMaps APIs, a developer API key is passed as a URL parameter, and if that API key is invalid then the authentication fails with the typical HTTP 403 (Forbidden) status code. I could modify my application to inject an invalid API key, but an easier approach is just to set up a rule that returns that status code for any request made, say, to the TomTom API.
which now matches any request including that string, regardless of the URI parameters
Now when I go back to the app and refresh the cameras currently in view, the request is intercepted by Fiddler and my app sees a 403 response, responding thus:
As you might have noted in the list of possible actions, there are a few well-known HTTP status codes along with some special outcomes including redirecting the request, dropping the connection, and modifying request headers. You can extend those options though by creating a specific response file complete with a payload.
Let’s say I wanted to test how the application would respond if, for some reason, the XML payload wasn’t well formed - due to a bug in the service for instance.
After refreshing the cameras from the application, the error now manifests itself as below:
In the starter kit, whenever you select a camera pin marker on the map, the image of that camera appears in the bottom left of the screen. In the implementation for this API call, the starter kit code checks for a missing image (as well as other errors) and displays a canned static image that’s included in the application package if it determines there’s a problem.
Here’s how I tested that scenario.
As a result any request for a camera image in the application brings up the canned image file that was provided with the application package:
I’ve provided few examples of how to use Fiddler for your testing, but there are a number of other features that you can leverage via the auto-responder including introducing latency and importing and exporting session archives (.SAZ) and rules files (.FARX) for replay and reuse.
Check out the AutoResponder Reference to explore all the options and help make your APIMASH application a rousing success!
Hi Jim -- another worthy mention here is RunScope (https://www.runscope.com - first learned of it from Chris Risner of the Windows Azure Mobile Services team.) It takes a slightly different approach in that it requires you to modify the URL the app is calling, including an encoded version of the real URL. As such it doesn't require installing the software on the calling machine, which is handy for Windows Phone and Windows RT debugging scenarios. From there, you use the portal to examine request/response headers and content, do playbacks, etc., in much the same way you described above.