As a software engineer with an experience of many years, I had worked with a dummy API or fake API a lot of times. Luckily or now I think unfortunately I had this experience only in expected cases. For instance the client app and web services were developing simultaneously and while developing client apps we were using predefined mocks with the similar data to what was expected from the real web service in near future. Such mocks were served either by internal service methods, files or by the local mock servers.
But recently we’ve got a project where most of the development process flows were totally not as expected. Our back-end app is supposed to communicate with a 3rd party through one more API, basically a Proxy API. This proxy API was developed by another SD company. BTW, below you may see the diagram of the server apps (APIs) and how they communicate:
Why such a weird API communication flow? This another SD company was a trusted partner of the 3rd party company for a long period. So, this Proxy API was basically a security solution, another security layer between us and a 3rd party. And that’s where things got wrong. The Proxy API company was way too slow with web services development, moreover the 3rd party was changing the requirements over and over again, so even we could not catch up with everything on time. So imagine the situation where you have 3 server apps, with a direct flow of data between them for instance 1 -> 2 -> 3 -> 2 -> 1 or vise versa. For communication between app #1 and app #2 we were using REST API services and webhooks for instant notifications. As for the communication between app #2 and app #3 - we did not care :) Probably they were using some SOAP protocol because the app #3 is very ancient and obviously untrendy.
Anyway, our API specifications were always changing and more than 50% of the web services were “in dev” status constantly. Obviously in order to continue development of our app without blockers we had to cover gaps of endpoints in a form of mock API or API stubs. We started as usual with a local approach by adding abstraction layers for communication with the 3rd party API, classes with dummy data, files, and local configs to switch between fake data or real endpoint. But switching between fake and real web service or vise versa using in-code configs all the time was not very handy, especially for UAT tests. What is more important, we had troubles with webhook notifications. We could do an end-to-end test properly only on the staging environments which is really frustrating.
So, we started to search for some existing solutions to our problems with API mocking. Our main requirement was gradually switching from dummy API to real API or even backwards when needed using some UI. Another important requirement was to allow end-to-end tests when we are running 2 server apps on 2 different local environments in totally different locations. After going through lots of existing tools, we’ve found one that matched all requirements we had. That seems to be a very brand new API mock tool called QuickMocker (https://quickmocker.com).
The greatest benefit across all other similar mocking tools was a Local Forwarder feature that allowed us to perform end-to-end tests even from a local environment. We had some trouble setting it up, because your API webhooks which are used only for receiving requests from the server app will need the CORS and OPTIONS method to be enabled. Obviously it is not a usual case to have CORS and OPTIONS in place for the server to server communication, but that was a “small price” for enabling communication between 2 server applications that are located on 2 different “localhosts” without any public DNS or IP address.
Another reason why we pick-up QuickMocker among all others was the Proxy and a nice UI to configure which endpoints should work as a proxy and which can be left as dummy API endpoints. Obviously it's not something unique and many other tools have this feature. But the nice thing is that all that we needed was in 1 single place!
Finally, QuickMocker recently added support for OpenAPI import. Because we use Swagger to define our web services, the import function might become handy. Though, we still need to test it.
Yeah, last but not least, QuickMocker has a pretty decent support for response templating with a lot of options to generate random and faker data. They support URL path patterns to match the request URL using Regular Expressions.
I think that’s all the features that we’ve used and you might find more out there. If you haven’t used API mocking solutions yet, QuickMocker could be a good start for you. And if you had opportunities to create some mock API already, I think QuickMocker could be an interesting alternative for you.
Top comments (0)