In this five-part article series, you learn how to manipulate your API behavior with a local proxy server. So far, this series has covered an introduction, taught you how to set up and configure Charles Proxy, and you have seen it in action. After presenting the Fiddler setup, we will now take a look at it in action.

Article series

  1. Introduction
  2. Charles Proxy Setup & Configuration
  3. Charles Proxy in Action
  4. Fiddler Setup & Configuration
  5. Fiddler in Action

Mission 1: Testing the Frontend Against Various API Responses

The todo demo API returns a JSON array with three objects, each with an id and title property. To demonstrate how to manipulate Fiddler's responses, we will change a single object's title to a very long one. As in Charles Proxy, we can do so via automatic breakpoints after each response. In the menu bar click "Rules" → "Automatic Breakpoints" → "After Responses".

Fiddler: automatic breakpoints

When triggering a new request, the response is halted, and we can modify it on our behalf.

Fiddler: editing the response in a breakpoint

Instead of editing the response body directly, you could also choose a predefined response from a list, such as different status code responses. Here you can see the result:

Resulting frontend after changing the response in Fiddler

As you see, this requires fewer steps to set up than the same result in Charles Proxy. The comfort comes at the price of some flexibility, though - which should be no problem in most cases.

Mission 2: Developing Against a Wrong API Implementation

Breakpoints are great if you want to do some quick tests. However, if you are trying to permanently change a response, maybe until a bug in the API has been fixed, breakpoints are not practical. We would like Fiddler to always respond with a predefined response.

Fiddler calls this feature "AutoResponder".

Before we activate it, we have to store a real response and modify it according to our needs. To do so, select the request from the list, right-click and then select "Save" → "Response" → "Entire Response" from the context menu.

Fiddler: store a response

After saving the response we'll edit it with any text editor to fit our needs. In this case, we want each object to contain an additional property done.

HTTP/1.1 200 OK
Server: Cowboy
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,PUT,POST,DELETE,OPTIONS
Access-Control-Allow-Headers: X-Requested-With,Content-Type,Cache-Control,access_token
Content-Type: application/json
Content-Length: 85
Etag: "1241236335"
Vary: Accept-Encoding
Date: Mon, 14 Oct 2019 13:20:27 GMT
Via: 1.1 vegur
Cache-Control: no-cache

[{"id":"1","title":"Todo 1","done":false},{"id":"2","title":"Todo 2","done":false},{"id":"3","title":"Todo 3","done":true}]

Next, we have to tell Fiddler's AutoResponder to use this file for the given request. This is done by selecting the "AutoResponder" tab on the right side and checking "Enable rules". Now we can drag and drop the request into the big text area and edit the rule to "Find a file...". We also need to check the "Unmatched requests passthrough". Otherwise, all non-matches requests will drop.

Fiddler: setup AutoResponder

After creating and changing the file and applying the autoresponder rules, we are now reloading the frontend to see the result.

Resulting fbroken rontend after changing the response in Fiddler

As the image shows, nothing shows up. There is no CORS error in the console or anything else suspicious. Within Fiddler, everything looks fine as well. Let's check the Chrome dev tools:

Chrome dev tools warning about a not finished request

Before we take a look at the solution, we want to explain a major difference between Charles and Fiddler. In Charles, we had only the option to save the response body. This resulted in missing CORS headers when the response was mapped to a file.

In Fiddler, we had the choice between "Save response body" and "Save entire response". We chose the latter to circumvent the problem of missing headers. However, this led to fixed headers, including the "Content-Length" header - which needs to get adjusted since the response body size changed!

Don't worry! We don't have to calculate this. We can just serve it wrong once and then look at Fiddler's recording, and we will see the actual length in the "Body" column:

Fiddler: content length

Again, we edit the saved response as follows:

HTTP/1.1 200 OK
Server: Cowboy
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,PUT,POST,DELETE,OPTIONS
Access-Control-Allow-Headers: X-Requested-With,Content-Type,Cache-Control,access_token
Content-Type: application/json
Content-Length: 123
Etag: "1241236335"
Vary: Accept-Encoding
Date: Mon, 14 Oct 2019 13:20:27 GMT
Via: 1.1 vegur
Cache-Control: no-cache

[{"id":"1","title":"Todo 1","done":false},{"id":"2","title":"Todo 2","done":false},{"id":"3","title":"Todo 3","done":true}]

Save and reload:

Resulting working frontend after changing the response in Fiddler

Mission accomplished. That was a bit easier compared to Charles as we were able to save the headers as well and did not have them added partially by a Rewrite tool as in Charles. Sure, we had to change the Content-Length header manually. However, that was much less of a hassle than the rewrite marathon.

Mission 3: Developing against an incomplete API

Like every todo app, ours needs the most used feature: adding todos. Unfortunately, the API has not yet implemented the respective endpoint. Let's fake it! The additional target will be POST /api/todo next to the already existing GET /api/todo.

We are using the AutoResponder for this task. At first, we create a Fiddler record by triggering the request from the frontend. That leads to a "400 Bad request" response that's ok for now. We just want the record in Fiddler to drag and drop it to the AutoResponder. Even though we already had a matching rule for this path, AutoResponder combined it this time with a method role as well!

Since we don't have a recorded response template for this route, we copy the one from the GET method, replace the response body, and save the file under a different name. Here is the result (with adjusted Content-Length):

HTTP/1.1 200 OK
Server: Cowboy
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,PUT,POST,DELETE,OPTIONS
Access-Control-Allow-Headers: X-Requested-With,Content-Type,Cache-Control,access_token
Content-Type: application/json
Content-Length: 42
Etag: "1241236335"
Vary: Accept-Encoding
Date: Mon, 14 Oct 2019 13:20:27 GMT
Via: 1.1 vegur
Cache-Control: no-cache

[{"id":"4","title":"Todo 4","done":false}]

That's the result in the frontend after adding two items:

Adding more faked items to the frontend

It's working! Do you remember the issues with Charles Proxy? We had to choose another endpoint path because Charles cannot to map different local files to different request methods. No problem for Fiddler, which is a huge plus in this mission!

Mission 4: Offline Development Against a Remote API

Recap: we have a working remote API and want it to be faked by our local proxy to be independent of the original during development. This is especially valuable when you are missing a stable internet connection.

A naive solution would be to drag and drop each possible path/method combination into the AutoResponder and match it against the according to the stored response.

Unfortunately, this is exactly what we need to do. There is no option to "batch"-map a whole parent path to recorded responses on your hard drive. If your API is big, you should only map those requests in AutoResponder, which are necessary for you to finish your current or next task.

In this demo, it's easy. There are only two endpoints, and we have them already covered at the AutoResponder. So let us test it by disabling the internet.

And now, we have the same problem as we had with Charles Proxy. Fiddler also tries to establish a CONNECT request to the server. However, in Fiddler, we can work around this by unchecking the AutoResponder checkbox "Unmatched requests passthrough".

In addition to the POST request, we also needed to map the OPTIONS request (CORS preflight request). So the complete AutoResponder settings are looking as follows:

Fiddler: final AutoResponder settings

With this configuration, we can develop against a remote API over HTTPS while being offline! This is another significant advantage of Fiddler over Charles Proxy.

Conclusion

Fiddler passed 4 of 4 missions. It is straightforward and effective to change response, add endpoints, and set up automatic response mappings. The only functional flaw compared to Charles Proxy is the inability to batch map a huge set of requests.

However, we did not cover the underlying script support ("Fiddler Script"), a powerful tool to inspect requests/responses and apply them programmatically With Fiddler Script we can even add new configuration menu entries.

Fiddler's succession candidate, Fiddler Everywhere, has a very clean UI and is being built natively for each platform (.exe/.AppImage/.dmg) without any further dependencies. But it still lacks fundamental features. It's worth checking it out from time to time!

Verpassen Sie keine Artikel mehr zu Tools & co

Melden Sie sich bei unserem kostenlosen monatlichen Newsletter an, um die aktuellen technischen Artikel unserer Experten zu den Themen Angular, .NET, Blazor, Azure und Kubernetes zu erhalten.

Bitte geben Sie eine gültige E-Mail-Adresse ein

Related Articles

tools
Fiddler Setup & Configuration: Mocking and Manipulating API Behavior With a Local Proxy Server - Part 4
In this five-part article series, you will learn how to manipulate your API behavior with a local proxy server. After an introduction, learning how to set up and configure Charles Proxy, and seeing it in action, we are now taking a look at the Fiddler setup and configuration…
Thinktecture Team
tools
Charles Proxy in Action: Mocking and Manipulating API Behavior with a Local Proxy Server - Part 3
In this five-part article series, you will learn how to manipulate your API behavior with a local proxy server. After setting the scene with an introduction and learning how to set up and configure Charles Proxy, we will now take a look at Charles Proxy in action. You will gain…
Thinktecture Team
tools
Charles Proxy Setup & Configuration: Mocking and Manipulating API Behavior With a Local Proxy Server - Part 2
In this five-part article series, you will learn how to manipulate your API behavior with a local proxy server. After setting the scene with an introduction, we will now learn how to set up the Charles Proxy and its configuration Article series Introduction Charles Proxy Setup…
Thinktecture Team
tools
Introduction: Mocking and Manipulating API Behavior With a Local Proxy Server - Part 1
When it comes to developing against an HTTPS/REST API, which we do not control ourselves, we face many problems regularly. Issues and hard to provoke edge cases may include a wrong implementation, an incomplete implementation or connection problems (dial-in issues, dropping…
Thinktecture Team