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 (1367
ms)
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 (134
ms)
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):