GeekFest #6 - WebApiProxy Update

It's been a long wait but the time has finally come for more interesting features on WebApiProxy. This video briefly outlines some of the many great features that were added to WebApiProxy in the past couple of months.

You can read more on this project by going to this introductory blog post  or at my recent blog about the update.

You can follow and contribute to the project on GitHub here

An update on WebApiProxy

This project initially started as a proof of concept but quickly grew into something very useful. For the past year or so it became quite popular and plenty of bugs came out of the cracks, but also useful feedback for features too!

You can download the packages straight from NuGet: WebApiProxy Provider and Web API C# Proxy Generator

Release notes

Here are a quick summary of issues resolved and features introduced in the latest version:

WebApiProxy Provider (version 1.0.2.4)

• OWIN support and compatible with self-hosted Web APIs
• Custom MEX endpoint address
• Enums and Constants support in DTOs
• Support for IHttpActionResult
• Extended documentation on DTOs
• Plenty of bug fixes & refactoring

WebApiProxy C# Generator (version 1.0.3.21)

• PCL compatible
• Generated code now contained inside project
• Opt-in for automatic code generation during build (now disabled by default)
• On-demand code generation using NuGet Package Manager Console
• No more reloading project for unresolved types
• Cleaner config file

Continue reading...

Fiddling around with XML responses

My year started with new challenges, first of which is malformed and unformatted XML. One of the requirements of a new project I'm working on is to read a simple XML response from a web service and do something with the data. How hard could it be?

Like any other developer, debugging tools like Fiddler is my friend. After capturing the response, I noticed that the contents were malformed and not properly formatted, but still "valid" XML.

Viewing the actual raw response, I realized that the apparent XML elements within the root 'string' element where actually encoded literal strings:

After accepting that I can't change the world, but definitely change the way you think about it, I decided to create a helping aid in the form of a Fiddler extension to help me make sense of the so-called XML.

Creating a Fiddler Extension

The first thing we have to do is create a new class library project in Visual Studio. We are going to target Fiddler version 4, so make sure the .NET target framework is set to 4.0.

Next, we need to add a reference to our project to the Fiddler assembly located at %programfiles(x86)%\Fiddler2\Fiddler.exe:

Now we can get coding! Add a new class to the project with the following assembly attribute:

To make this class visible to Fiddler we need to implement the IAutoTample interface and in the AutoTamperResponseBefore function, we can modify the response before it is served to the client.

This will use the provided Session object and replace the XML encoded angle brackets &lt; and &gt; as <  and  >  respectfully. While we at it, I've also decided to brand the response by adding a "Response-Hijacked-By" response header just because we can.

Lastly we need to build the project and copy the DLL to the Fiddler Scripts directory at %programfiles(x86)%\Fiddler2\Scripts\

Note: You may need to restart Fiddler if it was running.

Testing the goodness

Now when we execute the request, the extension kicks in and alters the response as proper XML:

We even got a special signature:

Till next time!

@FanieReynders