QuickMocker FAQ

Find out answers to questions related to API mocking using QuickMocker (intercept and debug requests, multiple methods, RegExp in the URL path, dynamic properties or shortcodes, local forwarder vs proxy, restrictions etc).


Questions

If you are not able to find answers to your questions, please send us a message using contact form or send us direct email to support@quickmocker.com.


Do I need to code anything to create mock API using QuickMocker?

No, you do not need to know any coding (programming) language in order to create API mock. All you need in order to create a mock endpoint is:

  • HTTP Method of the endpoint (e.g. POST, GET etc)
  • URL Path (e.g. /user/123)
  • Response HTTP Status (e.g. 200 for success, 401 for unauthorized access, 403 for access forbidden and so forth)
  • Response Body (optionally). Any kind of response body in whatever format you need (text, html, json, xml etc). There are no limitations.
  • Response Headers (optionally). Provide response headers using JSON format. For instance {"Content-Type": "application/json"}

That's it. In case you do not have this info, you can get sample of it from your back-end or 3rd party software engineers and use it inside QuickMocker until real web services development is completed.

So, simply create your project with its own subdomain and start adding your mock endpoints.

QuickMocker also supports Regular Expressions for URL Path and has some response templating support (shortcodes) if you need, but in most of the cases you probably won't require it.


Can I capture (intercept) and debug requests to my mock (fake) API?

Yes, that's one of the main features of QuickMocker. All the requests to your fake API are logged inside the Requests Log of every project separately. The records will appear in the Requests Log tab immediatelly after the request to your endpoint is executed. Each log record is an expandable panel. At first you can see request HTTP method, request URL, response status and date of the request. When you expand the panel you can see all the request and response details (headers and body for both request and response) in separate subtabs.

Intercept / capture and debug requests to mock /fake API


Can I set multiple requests methods per endpoint (URL Path)?

Yes, we support multiple request HTTP methods (e.g. GET/HEAD etc.) per endpoint. If endpoint has multiple methods, it will get label of the first method plus amount of other method (e.g. GET + 2) and will be marked with a dashed border like on the image below:

Multiple Methods per Endpoint


What is RegExp URL Path?

With the RegExp URL Path you can intercept requests using Regular Expressions (or so called search patterns). What does this mean? It means instead of creating multiple endpoints with a static URL path, you can define just one single endpoint that matches the required search pattern.

For instance, imagine you have an endpoint where you need to get user object, e.g. 'GET /user/‹id›'. In order to get multiple users with different IDs, you would have to define multiple endpoints with URL Path like 'user/1', 'user/2' and so on.

Using RegExp URL Path you can define one endpoint with the following path: '^user/[0-9]+$'. This URL Path will allow you to intercept any user ID.

After you create new Project our system automatically generates one RegExp endpoint for you, which intercepts all the

You may read more about regular expressions on Wikipedia.

Please note that RexExp URL path that does not have start (^) and end ($) symbols, will match the request URI at any position. E.g. if you set URL path for your endpoint to "mocker" and after that you send request to "/some-url/mocker/test" or to "/i-got-some-mocker-here", all of them will be intercepted by this endpoint. Same as you would send request just to "/mocker".


Why is there an endpoint already in a new fresh project?

After you create a new endpoint, we automatically generate a default endpoint which intercepts all the requests to your URL and responds with the 404 status code. It looks like on the screenshot below:

Default Project Endpoint

Because of this any request to your project (including unexisting) will be logged. Keep this endpoint at the bottom of your endpoints list so it has the least of priority. This means it will be triggered only in case there was no other matching endpoint.

Please note: in case you remove or disable this endpoint, you won't be able to debug requests that do not match any method name / URL Path among the endpoints you defined and therefore it will be more difficult to fix your incorrect requests. Thus we recommend you to always keep this endpoint enabled in the list.


What are Dynamic Response Properties (Shortcodes)?

In order to make your mock endpoint look and work more dynamic, you may find useful some of our shortcodes (dynamic response properties). This will allow you to make each response unique with its own data depending on the context like URL path or current date/time. Additionally it can generate unique or random values.

Currently we support following shortcodes:

  • (urlParam:‹index›)
    Allows to insert parameters (data) from the RegExp URL Path into the response body. Note: in order to use URL parameters in the response body, always wrap it in the parenthesis.
  • (dateTime:‹format›)
    Insert current date and/or time. Click here to see the list of characters to format the output.
    For instance (dateTime:Y-m-d H:i:s) will output current date and time, e.g. 2020-05-08 22:22:01.
  • (unixTime)
    Current Unix TimeStamp (amount of seconds since Jan 01 1970).
    Sample output: 1588507463.
  • (randomNumber:‹min›:‹max›)
    Generates a random number between the range of 'min' and 'max' numbers.
    For instance (randomNumber:100:200) will generate a random number between 100 and 200, e.g. 167.
  • (uniqueId)
    Generate a unique ID.
    Sample output: 4b3403665fea6.
  • (httpMethod)
    Gets current HTTP method.
    Sample output: GET.

See example below:

URL Path (RegExp turned on):

Response Body:

        
    

Requesting following endpoint using following Method/URL:

Can produce the following response body:

        
    

What is Local Forwarder?

Allows you to forward request you receive to your endpoint to any other URL including your local web server URL or IP address. This way you can process requests from the 3-rd parties on your development machines. This could be very handy while you develop integration with the 3-rd party web service using webhooks, which means you need to receive request from 3-rd party to your application, but you currently do not have a public (available on the Internet) URL. QuickMocker can receive this request, because it does provide you with a public URL and it can forward this request to your local application URL, which allows you to debug your code locally on your own machine during the incoming external request.

Please note that QuickMocker's Local Forwarder is working on the browser level, which means it can forward request to your app only when your Project's Reuqets Log tab is turned on. See picture below:

Requests Log Tab


You can also view response from your local app in the request log record along with usual request and response in the Forwarder Response tab. See image below:

Forwarder Response


Warning! By default your browser will block requests to your app URL in case you use HTTP (non-HTTPS) protocol (you can read more this behavior here). Please disable this security feature in your browser for QuickMocker site if you want to use Local Forwarder feature with your non-HTTPS URL. For instance in Chrome you need to allow Insecure Content inside QuickMocker site settings. For all the rest browsers please read through the following article.


Can I set Proxy for my mock API?

Yes, you can define proxy for any endpoint. When requesting your QuickMocker endpoint URL, the data will be forwarded to Proxy URL. After the response received from Proxy URL, it will returned back as it was a usual request to QuickMocker's endpoint.

You can configure default proxy URL for the project. It will be applied for all new endpoints you create. See screenshot below:

Configure default proxy for project

Except for this, you can change the Proxy URL for existing endpoints or override Proxy URL for new endpoints while creating or editing endpoint. See screenshot below:

Configure proxy for endpoint


What is the difference between Local Forwarder and Proxy?

Both of them have very similar priciple of a work. Still, the proxy works on the server level, but the local forwarder works on the level of your own browser. Lets see main differentce between those two:

Local Forwarder:

  • Works on the browser level
  • Forwards requests only when you open project's requests log tab in your browser
  • Is able forward request to any URL including your localhost URL

Proxy:

  • Works on the server level
  • Forwards requests all the time (does not matter if you open project requests log or not)
  • Unable to forward requests to your localhost URL

Can I set restrictions for my mock API (IP Address, Authorization Header)?

Yes, you can easily restrict your API endpoints either using IP Address or using Authorization Header.

First of all when you create or edit project, you can define default restriction rules for its future endpoints. See screenshot below:

Configure default restrictions for project

After that, when you create a new endpoint inside the project, by default it will get restriction rules that you've defined in the project earlier. Still, you can easily override them if there's a need. See screenshot below:

Configure restrictions for endpoint

IP Address field can be a comma separated list of IP Addresses (e.g. 192.168.0.1,192.168.0.2) or IP Ranges (e.g. 192.168.0.1/24,167.150.0.1/32) or both. In case IP Address of the client does not match, the response status will be 403 (Forbidden).

Authorization Header field could be set to any text value you wish. If client's authorization header does not match the one you've defined, the response status will be equal to 401 (Unauthorized).

All of the requests that do no pass the restriction rules are still logged in the Requests Log tab of the project and you can easily debug them.