Skip to documentation

Concept · Matching

Available

Select behavior from the request you received

DotMock first matches the protocol operation, then evaluates its enabled conditional responses. The default response remains the explicit fallback when no condition wins.

In this guide

  • Use one consistent expression language
  • Read every relevant REST request scope
  • Model state-aware outcomes such as 404
  • Debug the winning condition safely

Prerequisites

  • A DotMock workspace you can access
  • The API ID in $API_ID and its published runtime URL in $MOCK_URL when the example calls the mock
On this page
  1. Match the operation before the branch
  2. Read request data with bounded scopes
  3. Use state to represent what the system knows
  4. Keep branches specific and the fallback obvious
  5. Inspect the winner instead of guessing

Match the operation before the branch

For REST, method and normalized path select the endpoint. A path such as /users/{userId} captures userId in params. Conditional responses inside that endpoint decide which status, headers, and body to return.

expression
method == "GET" && path == "/users/73718b7c-f882-4639-87f4-4f7198f4d44e"

Read request data with bounded scopes

Use method and path for the request line; params, query, and lowercase header names for key/value input; body for parsed JSON; and hour for workspace-local time. Convert query text before numeric comparison.

Query and header
query["preview"] == "true" && header["x-plan"] == "pro"

Body and number conversion
body.total >= 100 && int(query["quantity"]) <= 10

Boolean composition
method == "POST" && !("x-blocked" in header)

Use state to represent what the system knows

State predicates let one request depend on earlier requests. A missing state entry is the normal way to model an unknown entity; a stored field can select lifecycle-specific responses.

404 condition
!state.exists("users-by-id", params["userId"])

Only active users
state.get("users-by-id", params["userId"]).status == "active"

Keep branches specific and the fallback obvious

Put mutually exclusive conditions in a readable order and leave the default response broad enough to be a true fallback. Keep the condition on the summary row and expand it for the complete response contract.

  • 404 — record does not exist
  • 409 — transition conflicts with stored state
  • 422 — request is structurally valid but semantically invalid
  • 429 — counter or quota exceeded
  • Default 2xx — the ordinary success path

Inspect the winner instead of guessing

A dry-run reports the matched endpoint, selected response, rendered status/body/headers, diagnostics, and proposed state diff. Change one request value at a time and rerun to prove each branch before publishing.