Recording HTTP/REST Traffic

HTTP and REST traffic often contain the parameters right in the URL, making it easy for MockMotor to spot them and use them for matching.

Unlike SOAP traffic, we can expect that the recorded service doesn’t require any manual modification.

Forward and Record Response

To record an HTTP or REST traffic:

1 Create a mock service that will simulate the real backend later
2 Create a forwarding response in that service
3 Point your application to that mock service and generate a traffic

The forwarding mock response will create a new mock response for each combination of request parameters that it sees. That includes HTTP query parameters and REST URL parameters.

Forwarding Response

A forwarding response:

  • Matches any HTTP method
  • Has no match by operation
  • Has no matching script
  • Contains the base URL of the real backend service in the Forward URL field
  • Has Record & Activate on
  • When recording is set to Record and Activate, the new mock is placed above the forwarding mock and begins handling the matching traffic immediately.

    When recording is set to Just Record, the newly created mock is placed below the forwarding mock. No traffic is reaching it. When the flow is completed, you need to move the recorded mock to its proper place in the list manually.

    Using HTTP Query Parameters for Matching

    An HTTP service request typically uses HTTP query parameters.

    Below, the request URL contains two parameters, lat and lon:

    https://api.weather.yandex.ru/v1/forecast?lat=59.939015&lon=30.315804
    

    When MockMotor records the exchange for an HTTP request, it extracts all query parameters and adds them to the match script. Added to the usual HTTP operation and relative URL, this creates an exact matching condition.

    As seen above, MockMotor records:

  • HTTP operation GET for matching
  • Relative URI /v1/forecast for matching
  • Query parameters lon and lat for matching
  • Response payload
  • Response time (1367ms)
  • Using REST URL Parameters for Matching

    A REST service request can also have parameters as a part of its URL.

    Below, the request URL contains rxcui parameter with value 18600:

    https://rxnav.nlm.nih.gov/REST/rxcui/18600/allProperties.json
    

    When MockMotor records the exchange for a REST request, it tries to extract all URL parameters and adds them to the match script.

    MockMotor not always can recognize a URL parameter. If the parameter looks too much like a regular URL segment - e.g. /rxcui/anazimin/allProperties.json - you’d have to update the match manually.

    Here, MockMotor recorded:

  • HTTP operation GET for matching
  • Relative URI /rxcui/{rxcui}/allProperties.json for matching
  • REST parameter rxcui for matching
  • Response payload
  • Response time (134ms)
  • A REST service can use HTTP query parameters too. In that case, MockMotor records both HTTP and REST parameters.

    Providing Keys when Query and URL Don’t

    In some cases, not all keys are passed in the URL or HTTP query parameters. Instead, the request payload contains the keys.

    Just like with SOAP traffic, MockMotor cannot tell which values in the payload are keys and which are not important. You have to help MockMotor by providing expressions that extract key values from the payload in the forwarding response:

    The extracted keys are placed into the match script of the generated mock along with their values (or lack thereof):