Stub web API easily using QuickMocker

QuickMocker is a relatively new, yet one of the most powerful and rapidly rising online API mocking tools. The main purpose of QuickMocker is allowing programmers to stub web services in a very simple and seamless way and on the other hand to support many important features that software engineers might need while developing, debugging and testing their apps. Combining these aspects was not the easiest task and it took a bit more than 1 year to get where we are now. Despite all the challenges, it was a very interesting and fun journey.

In this article we’ll look into the basics of the tool, how to start and finally we’ll dive into some advanced solutions that QuickMocker provides to its users in order to serve stubs or mocks.

Endpoint URLs including RegExp

First of all, QuickMocker is an online fake API tool which means that you can manage your dummy web services inside the browser through the web app. Right after the registration, you can create an endpoint collection (project) which is served over its own domain name, e.g. qwerty.api.quickmocker.com. The final URL of each endpoint will consist of this domain name and the endpoint URI (URL path) which follows after the slash, for instance qwerty.api.quickmocker.com/user. QuickMocker works only over the HTTPS protocol, thus the final URL of our sample endpoint will be https://qwerty.api.quickmocker.com/user. Another important thing is the ability to use regular expressions inside the URL paths which allows to match the endpoint using URI regexp pattern instead of hardcoded text. Find out more details about it inside the FAQ.

Multiple HTTP Methods per endpoint

One of the unique features that are available in QuickMocker is the ability to link multiple HTTP methods with the same URL. Yes, you may define one endpoint, but allow it to be requested using GET, HEAD, OPTIONS, POST, PUT, PATCH, DELETE methods. For instance this might be pretty useful for the front-end developers, because they do not have to create a separate preflight endpoint (OPTIONS method endpoint) for each of the corresponding endpoints. Using a similar approach you may create a wildcard endpoint that can intercept requests with any HTTP method and provide some common response.

Response Content

First of all, you may define any content inside your response headers and body, there’s no limitation here. In order to make life simpler for software engineers, there’s a separate drop-down field `Set Response Content Type` which allows to set the corresponding response header with predefined content types like JSON, XML, HTML, Plain Text etc. You may also edit the `Response Headers` field directly. By the way, there’s a 2 way binding between those fields, which means if you change content type value directly through the `Response Headers` field and it will be reflected in the `Set Response Content Type` field. As soon as the content type value is changed to one of the options inside the `Set Response Content Type` field, you’ll notice that the `Response Body` field will be using corresponding code highlighting thanks to the Monaco Editor which is a part of the VSCode. One more thing to mention is that QuickMocker is using JSON format to edit response headers and later to present them inside the Requests Log. In case you wonder how to define multiple headers with the same name, have a look into the FAQ. Finally, you may also set the response status code to whatever is required using the corresponding field, e.g. 200, 301, 404 and so forth.

Advanced Features

On top of the features mentioned above, QuickMocker provides a variety of additional more advanced features in order to create API mocks or fake APIs. For instance you can import endpoints from the OpenAPI schema (specifications), which might save a lot of time to create endpoints. Separately there’s a possibility to add dynamically generated data to the response body of your endpoint using QuickMocker’s shortcodes. Have a look at the sample endpoints / responses that are using shortcodes. There’s also the possibility to simulate stub API restrictions using the authorization header (401 response code) or allowed IP addresses (403 response code). Decide when you want to use a fake endpoint or real endpoint inside the QuickMocker with the help of Proxy. Yes, you may easily make any of your endpoints as a proxy server, which means you do not have to rebuild your app each time you want to switch between a dummy API or real web service. And finally the most interesting and unique feature is our local forwarder that helps back-end engineers to integrate, debug and test their webhooks without having to make the API public to the world.

Summary

QuickMocker works on top of the HTTP(S) protocol, allows flexible way of defining URL, HTTP Method(s), Response Headers, Body and Status, supports different content types and data formats, has a lot of advanced features to make APIs more sophisticated and almost dynamic. There’s obviously room for improvements and we are working on it every day. Taking into account all the possibilities of QuickMocker, you may easily mock any type of web API like RPC (both JSON and XML), REST or RESTful (including OData), GraphQL and even SOAP if you really need it. By the way, for the ease of development, QuickMocker is adding CORS wildcard headers, thus front-end engineers should not worry about anything and back-end engineers should be aware about it :)

Hope that this article gives you a sense of what QuickMocker is and it can be useful for your development processes. You may register a free account and try everything yourself. 

As usual, wish you happy API mocking ;)