[Feature] Path parameter matching (:id, {param} syntax)

[ragilhadi]

Summary

All path matching in Mimic is currently exact string equality. REST APIs heavily use path parameters like /users/123, /posts/my-slug, /orders/ORD-9981/items/2. Currently you need a separate mock file for every possible ID value, which is impractical.

Add support for named path parameters (:param and {param} syntax) so a single mock can match any value in that segment.

Motivation

Without path params, mocking a typical CRUD API requires:

mocks/get_user_1.json   → GET /users/1
mocks/get_user_2.json   → GET /users/2
mocks/get_user_3.json   → GET /users/3

With path params, a single file covers all cases:

{
  "method": "GET",
  "path": "/users/:id",
  "status": 200,
  "response": { "id": 1, "name": "Mock User" }
}

Proposed Configuration

Supports both :param (Express-style) and {param} (OpenAPI-style):

{
  "method": "GET",
  "path": "/users/:id",
  "status": 200,
  "response": { "name": "Mock User" }
}

{
  "method": "DELETE",
  "path": "/orgs/{org}/repos/{repo}",
  "status": 204,
  "response": null
}

Implementation Plan

src/types.rs

create_mock_key currently strips query strings and returns a literal path. Path-param mocks need a different lookup strategy — they cannot use a simple HashMap key.

Consider splitting MockStore into:

• exact: HashMap<String, Vec<MockConfig>> — fast O(1) for exact paths
• patterns: Vec<(CompiledPathPattern, MockConfig)> — checked in order for parameterized paths

src/matcher.rs

Add path pattern compilation:

pub struct CompiledPathPattern {
    pub original: String,
    pub regex: Regex,
    pub param_names: Vec<String>,
}

Convert :id → named capture group (?P<id>[^/]+) and compile to Regex.

In find_matching_mock:

1. First check exact map (O(1))
2. If not found, iterate patterns and test each regex
3. Exact matches score higher than pattern matches

src/handler.rs / RequestContext

Expose captured values:

pub struct RequestContext {
    // existing fields ...
    pub path_params: HashMap<String, String>, // populated during pattern match
}

Scoring

• Exact path match: base score 1000 (unchanged)
• Path param match: base score 900 (slightly lower, exact preferred when both exist)

Acceptance Criteria

• :param and {param} syntax both supported
• Captured values available in RequestContext.path_params
• Exact paths still matched with O(1) lookup (no regression)
• Correct priority: exact path > parameterized path
• Unit tests for single param, multiple params, nested paths
• README updated with path parameter documentation and examples