Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regexes in paths for route definitions #197

axiomabsolute opened this issue Apr 15, 2015 · 1 comment


Copy link

commented Apr 15, 2015

A project I am working on requires the following endpoints:


To avoid matching these, the get calls to define the routes could be ordered so that the call with the bound :id route param occurrs first, since new routes are pre-pended to the front of the routes vector.

As an alternative, I'd like to be able to define routes using regexes, like in Sinatra/Scalatra.

The solution I came up with was to add a new token to the SinatraPatternParser that allows users to escape a sequence of characters as a regex literal. This allows users to specify either the entire path as a regex, or only one portion of the path.

class SinatraPathPatternParser extends RegexPathPatternParser {
  /* ... omitted for brevity */
  private def token = splat | namedGroup | regexLiteral | literal // Add the regexLiteral token

  drivate def regexLiteral = ("r{" ~> """[^/}]+""".r) <~ "}r".r ^^ {
    regLit => PartialPathPattern(regLit, List())
  /* ... omitted for brevity */

The idea is that users could wrap part or all of a route path in r{..}r to specify that it should be treated as a regex literal. The portion inside the brackets is then added, as is, to the full pattern. The rest of the path will be treated normally.

For example, the get("/projects/:id") route above could be made unambiguous by changing it to get("/projects/r{(?!new)}r:id"), using a negative look ahead to assert that new doesn't appear after the second slash. Because the rest of the route definition is parsed as usual, the :id portion stil matches on the namedGroup token and works as you'd expect.

This seems like it could be a powerful addition to Finatra's routing capabilities. I know highly dynamic routes can be somewhat confusing and lead to unexpected bugs, so I'd like to do some testing to make sure that the proposed syntax doesn't hold any surprises and plays nicely with general urls.

Do you think this would be something worth investing time into?


This comment has been minimized.

Copy link

commented Sep 6, 2015

We've been moving away from supporting regexs in routes, but please reopen if this is a blocker for you.

@scosenza scosenza closed this Sep 6, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
You can’t perform that action at this time.