3.4Anatomy of a Pact Contract

{
  "consumer": { "name": "StorefrontUI" },
  "provider": { "name": "ProductService" },
  "interactions": [
    {
      "description": "a request for product ABC-123",
      "providerState": "product ABC-123 exists",
      "request": {
        "method": "GET",
        "path": "/api/v2/products/ABC-123",
        "headers": {
          "Authorization": "Bearer valid-token"
        }
      },
      "response": {
        "status": 200,
        "headers": { "Content-Type": "application/json" },
        "body": {
          "id": "ABC-123",
          "name": "Blue Widget",
          "price": 29.99,
          "category": "electronics",
          "in_stock": true
        },
        "matchingRules": {
          "body": {
            "$.id": { "matchers": [{ "match": "type" }] },
            "$.name": { "matchers": [{ "match": "type" }] },
            "$.price": { "matchers": [{ "match": "decimal" }] },
            "$.category": { "matchers": [{ "match": "regex", "regex": "electronics|clothing|food|other" }] }
          }
        }
      }
    }
  ]
}

Key Concepts

Provider States: Preconditions that must be true for the interaction. "product ABC-123 exists" means the provider's verification test must set up this state before replaying the request.

Matching Rules: Instead of exact value matching, Pact uses flexible matchers:

• type -- value must be the same type (string, number, boolean)
• regex -- value must match the pattern
• decimal -- value must be a decimal number
• like -- structure must match (same keys, compatible types)
• eachLike -- array where each element matches the example

This flexibility is critical: the consumer does not care that the product's name is exactly "Blue Widget" -- it only cares that a name field exists and is a string.