Developing application that connect to Web API can be quite a pain if we are not equipped with the right tools. Network issues, response format, request parameters, could add more to an already existing complexities. On the early days, I usually use Firebug for most of the task to debug Web API. Lately, however, I rely more on Fiddler. It does all that Firebug do for me plus much more. Compare to Firebug, Fiddler the debugging feels much more active since we can modify and manipulate a lot of things to test different cases on Fiddler itself without having to write test code or scripts. It sits between the application and Web API so we can build scenario to test each side.
Here are some of its use :
- Tracing request and JSON response. This is probably the most important ones. Tracing response on the code or by debugging in IDE can drain a lot of development time quickly. By monitoring it outside the application in realtime help us to focus more on the next step i.e: fixing code, add feature
- Emulate scenarios. The request / response can be emulated in Fiddler which enable us to see how the server or client response on certain request / response format and content without having to write the code first and do expensive IDE-based debugging
- Offline response. There are times when we want to rapidly and quickly test client behavior on certain response. Having to actually request to server could make the work take long since each request involve the whole request / response sequence. Fiddler could tap certain request format and give cached/predefined result instead. This will speedup the work since there is no actual network request happening. It could also help when we have issues with network availability when developing