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 connections), for example to a client’s VPN. Even though all those issues sound very different, they have one thing in common: the application does not receive the desired HTTPS responses. So, we are looking for ways to make us independent from the HTTPS API at development time. Wouldn’t it be nice, if there was a single tool to rule them all?

In diesem Artikel:

You Are Using the Solution Right Now!

When you are browsing the web, your internet traffic is most probably passing a couple of different proxy servers without your knowledge. There might be one at your company, your ISP, or the data center of the cloud operator where the website you are browsing is hosted on and so forth. They are all in place to either have more control over the traffic, to protect your privacy, to cache content, or to delegate traffic. There may be more use cases but those are the four most common ones.

Eventually, they are always between a source and a target. Receiving data from the source and passing it either filtered, manipulated, or untouched to the target. Proxies can even respond to you with cached data without bothering the target server again and again.

A proxy acts as an intermediary between two parties.

The Four Missions

Let us take a look at the problems that need to be solved, the “missions”:

1. Testing the Frontend Against Various API Responses

We want the API to respond with unusual responses like different HTTP status codes or specially crafted but valid values. The proxy should either replace the entire original response from the API or at least parts of it.

2. Developing Against a Wrong API Implementation

This is the same as above. We only want a different response than the original one.

3. Developing Against an Incomplete API

We are still waiting for the backend developers to implement the latest endpoint, discussed in the last meeting. We can not really continue our work without at least a fake endpoint that behaves real. The proxy can help out by answering with predefined responses to requests at certain endpoints.

4. Offline Development Against an External API

It happens too often that either the customer’s API is behind an unreliable VPN, or you experience an unstable internet connection. In both cases, the local development environment can not communicate with the backend. What now?

The proxy will help me by answering with previously recorded responses from the original API.

Two Viable Options: Charles Proxy and Fiddler

There are – at least – two interesting projects which could meet the requirements. First, there is Charles Proxy, written in Java and hence, available for Windows, Mac, and Linux. Maintenance and development are done by a single person. It is a closed source and costs about $50 for a single license. You can use it for free within a 30-day trial period.

The other one is Fiddler, written in .NET, and also available for all major platforms. It was bought by Telerik back in 2012 and is free to use since it is part of their “family of developer tools for .NET and JavaScript ninjas”.

In the second article of this series, you will learn how to set up and configure Charles Proxy.

Mehr Artikel zu API, Tools

Aktuelle Artikel, Screencasts, Webinare und Interviews unserer Experten für Sie

Verpassen Sie keine Inhalte zu Angular, .NET Core, Blazor, Azure und Kubernetes und melden Sie sich zu unserem kostenlosen monatlichen Dev-Newsletter an.

Newsletter Anmeldung
Diese Artikel könnten Sie interessieren

Git Fixup: Wie repariere ich meine Historie?

Git gibt uns mit der fixup-Option eine einfache aber effektive Möglichkeit, kleine Versäumnisse nachträglich so zu korrigieren, dass sie gar nicht mehr auffallen. Wie das genau geht, wollen wir in diesem Artikel erforschen. Mein Kollege Yannick Baron hat in seiner englischen Artikelserie zu Git bereits den interactive Rebase behandelt. Dort hat er auch die Möglichkeiten des fixup kurz angesprochen. Hier wollen wir uns etwas intensiver mit diesem Feature befassen.

Verwendung für Postman-Tests: ASP.NET Core API-Dokumentation mit Swagger – Teil 10 [Screencast]

Im zehnten und letzten Teil sehen Sie, wie Sie aus der Dokumentation auch Postman-Tests generieren können.

Code-Generierung aus der Dokumentation: ASP.NET Core API-Dokumentation mit Swagger – Teil 9 [Screencast]

Im neunten Teil sehen Sie, wie aus unserer Dokumentation vollständige Clients generiert werden können.

Swagger-UI anpassen: ASP.NET Core API-Dokumentation mit Swagger – Teil 8 [Screencast]

Im achten Teil sehen Sie, welche Modifikationen Sie am Swagger-UI vornehmen können. Zum Beispiel die Einbindung eines eigenen Logos in die Dokumentation oder einige weitere Features die Swagger mitbringt, welche aber nicht von Beginn an aktiviert sind.

Einbindung von Authentication & Authorization: ASP.NET Core API-Dokumentation mit Swagger – Teil 7 [Screencast]

Im siebten Teil sehen Sie, wie eine API, die Authentifizierung benötigt, korrekt dokumentiert wird.

Dokumentation versionierter APIs: ASP.NET Core API-Dokumentation mit Swagger – Teil 6 [Screencast]

Im sechsten Teil sehen Sie wie Sie vorgehen können, um mehrere API-Versionen gleichzeitig zu dokumentieren und wie Sie diese Versionen in SwaggerUI einbinden.