Added wildcard feature

[dharshan-0]

Related issue or discussion

Description

It closes #545 by adding wildcard routing feature.

It uses this *param_name to define wildcard.

Route::with_handler_and_name("/random/*path", generate_random, "generate-random"),

Type of change

• Bug fix
• New feature
• Documentation
• Refactor / cleanup
• Performance improvement
• Other (describe above)

Checklist

• I've read the contributing guide
• Tests pass locally (just test-all)
• Code passes clippy (just clippy)
• Code is properly formatted (cargo fmt)
• New tests added (regression test for bugs, coverage for new features)
• Documentation (both code and site) updated (if applicable)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Flag	Coverage Δ
rust	90.29% <100.00%> (+0.03%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
cot/src/router/path.rs	99.71% <100.00%> (+0.07%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ElijahAhianyo]

@dharshan-0 Thanks a lot for your contribution. This is a great start! Let's address the comments, and it's good to merge.

[ElijahAhianyo]

Currently, this branch implies that routes such as /foo/va*path are valid. I don't think we should support this, as it introduces ambiguity around how characters preceding the * should be handled.

To keep the routing semantics simple and predictable, wildcard segments should be required to begin with the * operator. In other words, patterns like *path would be valid, whereas va*path would not.

[ElijahAhianyo]

I also think that, for the sake of consistency with path params, we should have wildcards in curly braces as well. i.e {*path} instead of plain *path

[ElijahAhianyo]

It would be nice to add some type safety here and model wildcards explicitly. Instead of encoding wildcard semantics in the parameter name, we could introduce a PathPart::Wildcard variant and help the compiler distinguish between wildcards and regular path params.

[ElijahAhianyo]

I'm not sure we should include the * when storing the parameter name. Doing so forces downstream consumers to handle the wildcard marker themselves, which feels like a leaky abstraction.

For example:

let path_parser = PathMatcher::new("/{*path}");
assert_eq!(
    path_parser.capture("/foo/bar"),
    Some(CaptureResult::new(
        vec![PathParam::new("*path", "foo/bar")],
        ""
    ))
);

Instead, the * should be treated as part of the route syntax rather than part of the parameter name:

let path_parser = PathMatcher::new("/{*path}");
assert_eq!(
    path_parser.capture("/foo/bar"),
    Some(CaptureResult::new(
        vec![PathParam::new("path", "foo/bar")],
        ""
    ))
);

Similarly, when using ReverseParamMap, callers should not have to include the * in the parameter name:

let path_parser = PathMatcher::new("/users/{*path}");

let mut params = ReverseParamMap::new();
params.insert("path", "foo"); // `path` instead of `*path`

assert_eq!(
    path_parser.reverse(&params).unwrap(),
    "/users/123/foo"
);

[ElijahAhianyo]

For consistency with matching params, users/rand/{*path} should not match users/rand (however, users/rand/foo should be a match).

[dharshan-0]

@ElijahAhianyo Thanks for your comments, I will look into it.