One note: the order of the paths are key!

Given

ESP8266WebServer server(80);
server.on("/users/{}", handleUsersCall);
server.on("/users/{}/devices/{}", handleDevicesCall);
server.begin();

When calling http://YOUR_IP/users/3/devices/1 only the function handleUsersCall will be called.
With server.pathArg(0) == "3/devices/1"

In order to make this work:

ESP8266WebServer server(80);
server.on("/users/{}/devices/{}", handleDevicesCall);
server.on("/users/{}", handleUsersCall);
server.begin();

In order to make this work:

Could you add this explanation in your example ?

One note: the order of the paths are key!

Given

ESP8266WebServer server(80);
server.on("/users/{}", handleUsersCall);
server.on("/users/{}/devices/{}", handleDevicesCall);
server.begin();

When calling http://YOUR_IP/users/3/devices/1 only the function handleUsersCall will be called.
With server.pathArg(0) == "3/devices/1"

In order to make this work:

ESP8266WebServer server(80);
server.on("/users/{}/devices/{}", handleDevicesCall);
server.on("/users/{}", handleUsersCall);
server.begin();

The order no longer matters.
Path arguments may not contain '/'.
If a '/' needs to be a path argument, an URL encoded value can be used (%2F)

@Bmooij I've been looking at this from different angles and... the {} syntax bothers me, it's just not standard. Extending it would require extending the custom parser code, which again would not be standard, so I'd prefer to avoid it.
I'd personally prefer regex, but that can get complicated to use, and the patterns tend to be a bit error prone.
How about using glob (glob.h is available)? It's simple and standard, and makes use of a standard lib for the algorithm, so no custom parsing/string manipulation.

@devyte I'm open for every thing. I'm not familiair with glob. Can you show an example how the path would look like?

/users/*/devices
If you've ever done something like this in a Linux console, you've used glob patterns:
ls -l myfile*
or:
ls -l *cpp

glob is actually used for filenames in a dir. I think the underlying function to use is fnmatch (fnmatch.h). It returns zero or non-zero.
The following works in cpp.sh:

// Example program
#include <iostream>

#include <fnmatch.h>

int main()
{
    const char * pattern = "/users/*/devices/*";
    const char * path = "/users/lol/devices/lel";
    
    int ret = fnmatch(pattern, path, 0);
    
    std::cout << "ret=" << ret << std::endl;
}

Printout is ret=0, which means match.

This requires further discussion, so pushing back.

After using glob patterns, my personal preference goes to regex.
I added the regex support. Please let me know your thoughts on this.

usage:

server.on("^\\/users\\/([0-9]+)\\/devices\\/([0-9]+)$", []() {
    String user = server.pathArg(0);
    String device = server.pathArg(1);
    server.send(200, "text/plain", "User: '" + user + "' and Device: '" + device + "'");
  });

note:
The ^ upfront and $ at the end are required to detect it is a regex pattern.

This has a merge conflict, and needs further consideration to evaluate against the alternatives.
As a side note, I'm evaluating coexistence of all three.

Pushing back.

I forgot this pull request. Tomorrow I will fix the merge conflicts and implement the glob patterns, like @devyte proposed.

A problem that I encountered from a similar pull request, was that regex is a large include (100k).

@Bmooij #5467 I already implemented glob. All 3 alternatives are in PRs.
The question is: which do we use.
I was thinking of all three, with a different method nameing scheme, e. g. :

onRegEx() 
onGlob() 
onDontKnowNameOfThisOne()

With this, the regex bin increase should happen only if it is actually used, and yet all three alternatives are available.

@devyte What do you think of the following solution:

server.on("a/static/uri", callbackfn); // this will automatically transform to Uri("a/static/uri")
server.on(Uri("an/other/static/uri"), callbackfn);
server.on(UriRegex("^\\/users\\/([0-9]+)\\/devices\\/([0-9]+)$"), callbackfn);
server.on(UriGlob("/users/*/devices/*"), callbackfn);
server.on(UriBracket("/users/{}/devices/{}"), callbackfn);

That is a very good idea!
Notes for the uri objects:

• the constructors need to be explicit
• overloads in each for const char * and String args
• probably const String member
• UriBrace or UriBraces instead of brackets
• mind move semantics
• getter methods

@Bmooij could you please pick up the three implementations from the PRs and make a new one with your idea? That new one would then supersede the three.

There is an issue when I want to include <regex>

lib\ESP8266WebServer\src/detail/RequestHandlersImpl.h:25:13: error: 'regex' is not a member of 'std'

Closing in favor of #6696.