Named path parameters

[bugdea1er]

For now, the server is putting the responsibility on me to write the correct regex and duplicate it in every path. For example, it is not enough to use (.+) for project ID for paths

GET /projects/11/files HTTP 1.1

and

GET /projects/11 HTTP 1.1

since it would also require to bind them to the server in the proper order.

I suggest to adopt some familiar syntax for parameters in paths (like, {id} or :id) and do not require to write regexes from the user:

srv.Get("/projects/{id}/item", handler);

Such syntax would also allow me to get parameter values by the key instead of the order with some kind of operator[]:

void handler(auto req, auto res) {
  auto project_id = req["id"];
}

[yhirose]

@bugdea1er I am not planning to support {...} syntax because it requires a drastic change in the parser.

Is the following way enough in your case?

srv.Get(R"(/projects/(\d+)/item)", [](auto req, auto res) {
  auto id = req.matches[1];
});

[bugdea1er]

@yhirose It will go as a temporary solution, but as for me, it’s more correct to catch all requests that match the URL, and only on the backend side decide whether this format is suitable or not (responding with "404 Project not found" for /projects/string)

If you are ok with this, then you can leave the ticket open. Maybe someday I or someone else will throw a pull request on this topic.

Also during these days, I also thought that named path parameters are also an interesting feature.

[yhirose]

@bugdea1er one of the possible problems to introduce the {...} syntax is that it conflicts with a Regex repetition operator like [1-9][0-9]{3} which also uses curly braces. So I don't think it's easy to seamlessly support both the named path parameters and the current regular expression match implementation in cpp-httplib... I guess we have to implement a completely different parser for the named path parameters and allow users to pick either one based on their requirements.

On my side, I am not planning to implement the feature since I am satisfied with the current regex way. Are you seriously thinking of implementing the feature in the near future?

[bugdea1er]

@yhirose we are planning to modify this library in our project to support such named parameters. I think we can try to support both old and new syntax and if we succeed we will send you a pr