Allow finding all matches

[StupendousYappi]

I'm working on a web framework that closely integrates with Postgres, and one feature I'd like to offer is the ability to define preprocessors that run before the main request handler does. My request handlers currently use matchit for routing, and I'd like to let users register preprocessors using the same syntax. But whereas every request should only match one request handler, it should potentially be able to match multiple preprocessors. The current Router API won't let me retrieve all the matching paths, so to do this today, I'll need to create a separate router for every preprocessor, and call at on all of them (I'll look at the static prefix portion of each preprocessor paths to skip evaluating some of them).

Would providing a Router::all_at method that returns a Vec<Match> of all the matches for a path be a reasonable feature for this crate?

[ibraheemdev]

I'm not sure I understand what Router::at_all would do. Should it return all nodes with matching prefixes? Or do you want multiple values at a single route?

[StupendousYappi]

Multiple values at a single route. Maybe something like this:

  use matchit::{Router, Match};

  let mut router: Router<String> = Router::new();
  router.insert("/api/one", "a".into());
  router.insert("/api/two", "b".into());
  router.insert("/api/{value}", "c".into());

  let result: Vec<Match<&String>> = router.all_at("/api/one");
  assert_eq!(2, result.len());
  assert_eq!(vec![], result[0].params);
  assert_eq!(&"a".into(), result[0].value);
  assert_eq!(vec!["one"], result[1].params);
  assert_eq!(&"c".into(), result[1].value);

[ibraheemdev]

I see, that's interesting. /api/one and /api/{value} are overlapping routes, but we prefer the static match over the dynamic one, and you instead want a way to return all possible matches. I think that can work, it just means we need to continue the search instead of preferring the static match.

For a routing framework, it might be easier for you to allow users to group routes and statically attach middleware to groups of routes. That said, this certainly seems like something we could support.

[StupendousYappi]

I'll look into grouping routes, but this web framework uses SQL migrations to define APIs. So you might define your preprocessor (in practice, a SQL function) in one SQL file, and an API that falls under it in another SQL file that gets executed independently months later. One of the use cases for this feature is to let users easily define logic that will be executed before all of their APIs, so in many cases, all the APIs will be in the same group.