Add named path parameters parsing (Implements #1587)

[bgs99]

As discussed with @bugdea1er, I have implemented named path parameter parsing.
New parser is accessible by a different set of Get/Post/Put/Patch/Delete/Options methods with a suffix "Simple" (open for suggestions).

Example of usage from tests:

  svr.GetSimple("/users/:id", [&](const Request &req, Response &) {
    EXPECT_EQ("user-id", req.path_params.at("id"));
    EXPECT_EQ("foo", req.get_param_value("param1"));
    EXPECT_EQ("bar", req.get_param_value("param2"));
  });

[bugdea1er]

@yhirose one of the possible solutions for this naming is to hide the new functions behind an optional compilation flag like you did with ssl support. I doubt that anyone would use both options for paths in the same project

We want your opinion

[yhirose]

Great pull request! Indeed, the 'Simple' suffix might cause confusion among users. Personally, I would prefer to retain both the regex matcher and the path params matcher. How about checking at runtime whether the path includes /: at least once, and based on that, determining if it's in 'path params' mode? The code could be modified as follows:

inline Server &Server::Get(const std::string &pattern, Handler handler) {
  auto matcher = pattern.find("/:") != std::string::npos
    ? detail::make_unique<detail::PathParamsMatcher>(pattern),
    : detail::make_unique<detail::RegexMatcher>(pattern);

  get_handlers_.push_back(std::make_pair(matcher, std::move(handler)));
  return *this;
}

By following the above approach, we can maintain just one Get method with a minimal impact on performance. The only limitation of this approach is that we can no longer utilize /: in the regular expression pattern. However, I believe this constraint is reasonable and won't cause any inconvenience for existing users. What do you think?

[bgs99]

Great idea!
I was thinking about something like that but was not sure how you would judge the risk of breaking some convoluted setups.
I will update the PR tomorrow, if nothing goes wrong.

[yhirose]

Or something like this?

inline std::unique_ptr<detail::MatcherBase> Server::make_matcher(
    const std::string &pattern) const {
  return pattern.find("/:") != std::string::npos
         ? detail::make_unique<detail::PathParamsMatcher>(pattern),
         : detail::make_unique<detail::RegexMatcher>(pattern);
}

inline Server &Server::Get(const std::string &pattern, Handler handler) {
  get_handlers_.push_back(
      std::make_pair(make_matcher(pattern), std::move(handler)));
  return *this;
}

Could you please also update README to show calling examples? Thanks a lot!

[bgs99]

Done.
Used an if statement instead of the ternary operator though, as the latter won't compile with different argument types.

[yhirose]

Thanks for the fine contribution! I believe many users will like the new feature. 👍

[yhirose]

@bgs99 could you take a look at #1805? It seems like this PR creates the issue. Thanks a lot!