Mock server unable to match method type/mock path when using TEMPLATE parameters

🙋 Help
, , ,
1

I have created a collection featuring three requests based on the following method and URL:

GET 200 OK

{{url}}{{path}}/subject/{{subject_nr}}/honden

Headers

Accept application/json
x-api-key {{apiKey}}
x-mock-response-code 200

I have then created a mock server for the collection featuring the following mocked request/response:

Example Request : GET 200 OK

curl --request GET \
  --url 'http://{{url}}{{path}}/subject/{{subject_nr}}/honden' \
  --header 'Accept: application/json'

Example Response : 200 OK

{
  "datum_ingang": "2/5/18",
  "totaal_aantal_honden": 1
}

NOTE: The mock server shares the same environment the collection uses, all the abovementioned environment variables are substituted correctly at runtime.

When the request is sent to the mock server, the following output is shown in the console:

GET

https://1f586124-667b-4d20-b3cc-ce66c99d0cba.mock.pstmn.io/urds/wrd/api/hond/v1/subject/0303200001/honden

* * Request Headers:
    * accept:"application/json"
    * accept-encoding:"gzip, deflate"
    * cache-control:"no-cache"
    * host:"1f586124-667b-4d20-b3cc-ce66c99d0cba.mock.pstmn.io"
    * postman-token:"4e5fff38-af47-4994-89e5-1e1e9ca75668"
    * user-agent:"PostmanRuntime/7.3.0"
    * x-api-key:"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    * x-mock-response-code:"200"

* * Response Headers:
    * access-control-allow-credentials:""
    * access-control-allow-headers:""
    * access-control-allow-methods:""
    * access-control-allow-origin:"*"
    * access-control-expose-headers:""
    * connection:"keep-alive"
    * content-encoding:"gzip"
    * content-length:"185"
    * content-type:"application/json; charset=utf-8"
    * date:"Thu, 25 Oct 2018 10:08:25 GMT"
    * etag:"W/"d5-wZgN2LuPyvxuKCxlKWOeZw""
    * server:"nginx"
    * vary:"Accept-Encoding"
    * x-ratelimit-limit:"60"
    * x-ratelimit-remaining:"59"
    * x-ratelimit-reset:"1540462165"

* * Response Body:
    * error:
      * name:"mockRequestNotFoundError"
      * message:"We were unable to find any matching requests for this method type and the mock path, '/urds/wrd/api/hond/v1/subject/0303200001/honden', in your collection."

404

218 ms

My questions are:

  1. Why is this happening?
  2. Are TEMPLATE parameters in the path supported by the mock server?
2

@Wodan - Template parameters are supported by Mock Servers as long as you are creating the mock using an environment variable that has variables that resolve to those variables.

You have mentioned that you have associated an environment with your mock that has these variables. Can you make sure that the values that you have specified for those variables match the values that you sending in your mock request and try again?

Eg. url should be set to mydomain.com (Exact value does not matter for this variable), path should be set to /urds/wrd/api/hond/v1/ (Exact value matters here, also not the leading / that separates it from the url) and subject_nr should be set to 0303200001 (the exact number should not matter here).

3

Pratik,

Thanks for your reply.

As you can see in my first post, I provided the full URL that Postman is actually using to send the request to:

GET 200 OK

https://1f586124-667b-4d20-b3cc-ce66c99d0cba.mock.pstmn.io/urds/wrd/api/hond/v1/subject/0303200001/honden

Headers

Accept application/json
x-api-key xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
x-mock-response-code 200

This information is copied from the Postman documentation for the API and, as you can see, the TEMPLATE parameters are found in the environment and substituted correctly, as you stated.

The URL showed in the console is the same:

GET

https://1f586124-667b-4d20-b3cc-ce66c99d0cba.mock.pstmn.io/urds/wrd/api/hond/v1/subject/0303200001/honden

Request subject_nr:

0303200001

Response Body:

  • error:
    • name:“mockRequestNotFoundError”
    • message:“We were unable to find any matching requests for this method type and the mock path, ‘/urds/wrd/api/hond/v1/subject/0303200001/honden’, in your collection.”

Hence, I assume the problem is not being caused by a faulty matching between environment variables and actual URL TEMPLATE parameter values.

Looking forward to here from you guys…