03.0 Mappings

Sample Mapping

-  request:
      method: POST
      #method: *
      #method: ["POST", "GET", "HEAD"]
      url: /stubs/(admin|staff|customer|security)/([0-9]+)/2
      post: password=([a-zA-Z0-9]+)
      headers:
      		custom: (\w)
      query:
      		custom: (\w)      
   dbset:
      db: <% url.1 %>
      key: <% url.2 %>
      strategy: random

   response:
      proxy: proxyURL
      status: 500
      latency: 3000
      #latency: [1000,3000]
      #body: single line response
      parser: 
        type: jsonToNimn
        options:
           schema: path/of/schema/file
      body: >
      	multiple line response
      	another line
      strategy: first-found
      file: authentication.xml
      files: ["authentication.xml", {"name":"fault.xml","latency" : 200, "status":500}]
      headers:
      		custom: <% url.2 %>
      		content-type: application/nimn
      sendasfile: true

Request response mappings are defined in yaml format. You can place all yaml files in mappings folder of project and Stubmatic will pick them on directory scan. On the other hand, if you use configuration file you can list all mappings file in configuration file.

All possible mapping attributes are mentioned above. Many of them can not appear together. Let's discuss some of them in short.

There are 3 section of a mapping: request,dbset, and response.

request: This section is used to match the incoming request and capture data to use it in dbset or response part. method, post, headers, url all are http request part which are pretty much self explainable. Stubmatic do exact match for url and `header values.

You can use regular expression to match the data and RE groups to capture data. Nested RE groups are also supported. If you capture something from url value, you can use it as <% url.1 %>,<% url.2 %> and so on. You can use this captured data in dbset mapping, response mapping or response file's body.

dbset: dbset section helps to map a request with dbset. You can consider dbset as a list of keys or a db table. You can use it to serve different response for same kind of request or to fill data into response skeleton. We'll discuss this section in detail on dbset page.

response: headers and status attributes of this section are pretty much explainable. latency is used to serve the response with a small delay. It helps to test some negative scenarios or in performance tests. body, file, and files are used to serve response body. You can have either of them. If you multiple of them then Stubmatic will not give error but will serve body on priority then file and then files. strategy can be used to define which file of files array has to be served. If sendasfile property is set to true then the file data will not be served as response body but as a file.

See sample mappings.

Default Configuration

It helps to reduce the size of mapping file, avoid repeated attributes in each mapping. These mapping would be applied to all mappings. Below mappings are default mappings. You even need not to specify them in your configuration file too.

"mappings": {
  "default": {
    "request": {
      "method": "GET"
    },
    "response": {
      "strategy": "first-found",
      "latency": 0,
      "status": 200
    }
  },
  :
}

Headers & Query Params

Following mapping can be used to match a request don't have specified params

-  request:
      url: /stubs/neagative/header
      headers:
        static: ^
        reg: ^

   response:
      body: success

This mapping is helpful to stub negative responses