A response can be correct even when its values change. A movie API may return a different ID, title, or year on every run, while a consumer still requires the same usable data shape. A matching rule records that distinction in a Pact interaction: it tells contract verification how to compare dynamic request or response values rather than requiring one literal example value. section 3.3 section 4.3.4
Matching rules make a contract less brittle than an exact-value check. For a movie list, `eachLike(EXPECTED_BODY)` accepts entries shaped like the example; an integer ID becoming a string fails, but a different integer does not. The example remains useful contract data while the rule expresses what the consumer actually depends on. section 4.3.4
Apply Pact matching rules at several interaction boundaries:
- Use JSON body type methods to require strings, integers, dates, IP addresses, or other supported value forms; optional arguments supply example values in the generated contract. section 5.2 section 5.3.1
- Use path matching when a URL contains a dynamic value, such as a movie name constrained by a regular expression. section 5.3.1
- Use header matching for variable authorization data, allowing verification to substitute a real API token. section 5.3.1
- Use query matching to define a parameter key, a regular expression, and an example value that can be replaced against provider data. section 5.3.1
A typed movies response
Build a JSON array whose elements each contain an integer `id`, string `name`, and integer `year`, then attach it as the 200 JSON response body. The resulting interaction checks the expected movie structure without fixing every returned movie value. If no example is supplied to a type method, Pact can generate a random one. section 5.2 section 5.3.1
Listing 5.19 Matcher types example
PactDslJsonBody body = new PactDslJsonBody()
.stringType("name", "Lewis")
.integerType("no.")
.date("todaysDate", "mm/dd/yyyy", date)
.ipAddress("localAddress");
Compare generic and specialized body matchers, including string, integer, date, and IP address rules with example values. section 5.3.1
Keep matching focused on the consumer-visible contract: request details, expected response data, and dynamic-value rules belong together in an interaction. Matchers can cover bodies, URL paths, headers, and query parameters, so select the boundary where variability occurs instead of treating all values as fixed fixtures. section 3.3 section 5.3.1
