Mocks

The workspace contains one or more mocks, which match HTTP requests, render the response, and return that response to the client. A mock consists of a name, request matching part, and response rendering part. Name is an optional value that helps to identify particular use case mock handles. The request matching section defines a set of matching rules applied to every request arriving at the workspace. The response rendering part defines the response status code, headers, and body of the response.

In general, SmartMock.io does not force any rules nor does it favor any HTTP-based communication paradigm, like REST or SOAP. It is possible to create mocks which violate HTTP standards. It's up to the mock creator to specify the appropriate response status code, headers, and body. Using the provided set of request matchers and mock types (Static, Template, Dynamic), it's possible to simulate a broad spectrum of service integration through the HTTP protocol.

Create New Mock

To create a new mock navigate to Workspace Details of the workspace, you would like to add mock to and click Create Mock button. In the mock form:

To create a new mock, navigate to the Workspace Details section of the workspace to which you would like to add a mock, and click the Create Mock button. In the mock form:

• Complete the Name field. It should be a descriptive name identifying the use case the mock simulates
• (Optional) Set a priority for the mock - more details

Request section:

• Enter a path matching expression into the Path field - more details
• Select an HTTP method in the Method field
• (Optional) Enter a content type to match in the Content Type field
• (Optional) Add advanced matchers for headers, path parameters, query parameters, cookies or body - more details

Response section:

• (Optional) Specify type and parameters defining the duration of delay before a response is returned
• Select what type of mock you would like to create, and, depending on your selection, enter response status code, headers, and the body. See the appropriate documentation section for each type of mock for more information
• (Optional) You may configure a mock to simulate fault - mode details

Please note that the number of mocks you may create depends on the plan you are subscribed to.

Test Mock

After a mock is created, it's possible to verify its behavior and output. There are external tools like curl or other HTTP clients that can be used. Also, SmartMock.io provides a user interface widget to verify generated responses, matching rules, and the correctness of Template/Dynamic mock code. See Testing Workspace for more details.

Request Matching

SmartMock.io supports matching of incoming requests using the following fields:

• HTTP Method (GET, POST, PUT, DELETE, HEAD, OPTIONS, PATCH, TRACE)
• Path
• Path parameters (extracted from Path)
• Headers
• Cookies
• Query parameters

Path

A path matching expression is a string with zero or more embedded parameters. Parameters can optionally specify the regular expression used to match their values. The default value matches any text and terminates at the end of a path segment, but other values can be used to alter this behavior. Variables extracted from the path during the matching process are later available in the request model as path parameters for template and dynamic mocks.

Non-parameter parts of a path matching expression are case-sensitive - More details

Examples

• /api/v1/order/1234 - Exactly matches path /api/v1/order/1234 and does not put any path parameter into the request model on successful match.
• /api/v1/order/{orderId}/item/{itemId} - Matches paths /api/v1/order/1234/item/2345, /api/v1/order/abc/item/def and puts two path parameters into the request model on successful match.
• /api/v1/order/{orderId:\d+} - Matches path /api/v1/order/1234 and puts a single path parameter orderId into the request model on successful match. Does not match /api/v1/order/abc because a regular expression specified beside a variable name matches digits only.
• /api/v1/{var:.+}/1234 - Matches anything, like /api/v1/person/1234 or/api/v1/order/1234, even /api/v1/order/aaa/item/1234 and puts a single path parameter var into the request model.
• {any: .*} - Matches any path. This pattern (in conjunction with mock priority value) may be useful to simulate a global 404 response.

Header, Path Parameter, Query Parameter, Cookie

Besides the HTTP method and path, you may specify some matchers for other named fields of the request: header, path parameter, query parameter, cookie. To do this, in the New/Edit Mock view, click Add Advanced Matcher and specify the Matcher type, Field name, Operator and Pattern.

The following matching operators are available:

• equals - At least one field of given type and name exactly equals a given pattern.
• does not equal - No field with given type and name exactly equals given pattern.
• contains - At least one field of given type and name contains a given pattern.
• does not contain - No field with the given type and name contains given pattern.
• matches - At least one field of the given type and name matches (regexp) given pattern.
• does not match - No field of the given type and name matches (regexp) given pattern.
• is empty - Field of given type and name is specified, and its value is an empty string.
• is not empty - Field of given type and name is specified, and its value is not an empty string.
• absent - Field of given type and name is not present in the request.
• exists - Field of given type and name is present in the request (with any value).

If you find the set of operators too narrow and have a suggestion for a new one, please contact our support.

Body

Matching of the request body happens the same way as for headers, path parameters, query parameters, and cookies. The only difference is that body is not a named field, i.e., does not need Field name to be specified.

Mock Priority

In some situations, you may want to create two or more mocks in the way that a single request could match more than one of them. Matching for these mocks would 'overlap.' Such a use case could be catching all URLs that do not match any specific case (for instance, generic 404 errors) for your mock. Specifying Priority for the mock may help to solve such a problem. The lower priority, the sooner a mock is checked to see if it matches the request. When two mocks' priorities are the same, and both match the request, the most recently added is selected.

Example You specify "Mock 1" matching path /api/v1/order/{orderId} with priority 1, "Mock 2" matching path /{var:.*} with priority 10 and "Mock 3" matching path /api/v1/user/{userId} with priority 20.

1. When a request with path /api/v1/order/1234 arrives, it is matched against:

   • "Mock 1" - match and response of Mock 1 is returned

2. When a request with path /api/v1/user/abcd arrives, it is matched against:

   • "Mock 1" - no match
   • "Mock 2" - match and response of Mock 2 is returned,

There will be no matching against "Mock 3" because it's "shadowed" by "Mock 2" which matches all paths.

CORS

By default, CORS headers are attached to the response for every request containing the Origin header. When SmartMock.io detects a CORS preflight request, it returns a response with CORS headers regardless of whether the mock was matched or unmatched. For simple CORS requests, CORS headers are also attached for matching mocks. If you want to override this behavior, please set CORS headers in the mock definition. The table below presents the value of CORS headers returned by default.

Header name	CORS request type	Default value
Access-Control-Allow-Origin	Simple, Preflight	Value requested in Origin header
Access-Control-Allow-Credentials	Simple, Preflight	true
Access-Control-Expose-Headers	Simple, Preflight	*
Access-Control-Allow-Methods	Preflight	Value requested in Access-Control-Request-Method header or GET,POST,PUT,DELETE,HEAD,PATCH,OPTIONS,TRACE
Access-Control-Allow-Headers	Preflight	Value requested in Access-Control-Request-Headers header or '*'
Access-Control-Max-Age	Preflight	3600

Response Delay

Response delays may be configured for every mock and can be used to simulate long response times from upstream services. The maximum delay value is 30 seconds. Delays are performed after the invocation of template/dynamic mock or proxy request.

The following table describes available delay distributions:

Distribution name	Description
Random (uniform distribution)	A uniform distribution, also called a rectangular distribution, is a probability distribution that has constant probability. Delay duration is a random value chosen from the range between Minimum and Maximum parameters.
Random (normal distribution)	A normal distribution is a very common continuous probability distribution. Delay duration is a random value selected from normal probability distribution parametrized with Mean and Standard Deviation parameters. Value generated from normal distribution may be negative (depending on parameters). In that case no delay is applied.
Constant	Delay duration is a constant value specified by Value parameter

Fault Simulation

To test unexpected behavior other than 4XX and 5XX HTTP status codes, SmartMock.io can simulate a few other types of problems:

Fault Type	Description
Empty response	Closes TCP connection before any response is sent back to the client
Random data	Sends random alphanumeric data chunk to the client and closes TCP connection
Malformed response	Sends HTTP 200 status code and random alphanumeric data chunk to the client and closes TCP connection
Reset TCP/IP connection	Resets underlying TCP/IP connection causing "Connection reset by peer" error

To configure unexpected behavior for a mock, select Simulate Fault instead of Static/Template/Dynamic Mock in the Response section of the mock.

---

Last update: December 9, 2020