- Does this library bring real benefit to C++ developers for real > world use-case? Yes definitely. I believe probably every programmer has written a (mostly crappy) URL-parser before, and I would be more
- Do you have an application for this library? Yes. Besides parsing incoming HTTP-Requests, I would use it to
Hi, I'm not a boost developer, but as someone who has to deal with URLs (for calling or implementing Web-APIs) at his job frequently, I want to give my two cents as a most likely user of this library. I hope this is OK (I won't give a recommendation to accept or reject though). I spent about 2.5h integrating the library into our program and tried some simple parsing and constructing of urls. I used MSVC2022 which worked without problems. than happy to replace our parser with this library. programmatically construct urls to call external Web-APIs. One of the more common scenarios in our applications is the construction of urls after the user provided some login credentials and often hosts/port combinations. Also a prefix path is often needed (for example to differentiate between a demo or beta service and the real production api). I feel like the current API design lacks a bit in this regard. To construct a new url i did the following: auto url = boost::urls::url{}; url.set_scheme("https") .set_host("special-api.com") .set_port("443") .set_path("/prefix/api/v1/"); url.segments().push_back("applications"); url.segments().push_back(applicationId); url.segments().push_back("devices"); url.params().append("since", "2022-01-01"); The url::set_... methods seem to follow a fluent api design which is nice, but unfortunately they return url_base&. So I can't construct a url inside a function call like: httpClientGet(url{}.set_host(host).set_path("some/path")) Being able to add segments is great. Personally I'm a big fan of overloading the /-operator to append paths like in the filesystem library, because I think this results in more readable code. The example of above could become: httpClientGet(url{host} / "some/path") I really like that the library offers different parse_ functions, so an user can choose the appropriate one depending on the context. But it is a shame that there are no semantic types to go along with them. As mentioned above we often have the case that we have to construct a url by combining a prefix path with the actual path of the resource. As this prefix path has to be absolute and the resource path relative I want to use 2 distinct types for them. It seems to me, the resolve() function has a similar problem. The documentation states that the base url has to satisfy the absolute-URI grammar. Wouldn't it be great to have a distinct type for this? BTW why is there only an authority_view and not an owning container? Seems inconsistent to me. Its nice that there are functions to manually do percentage encoding, but I would prefer (additional) simpler functions which just return a std::string. It would be nice if the library also provided the default port numbers for the schemes. I know the documentation states that this is not part of the URL-protocol, but I gonna need that information if I use the library.
- Is the documentation helpful and clear? Mostly yes. Reading the "Quick Look" page is enough to get started with using the library which I appreciate. I also like the help card, which would be greatly improved by adding links to the reference pages.
I skipped / skimmed the Customization and Concept pages. I would recommend not to start your example page with a 700 lines implementation of magnet links, that's super intimidating. Something I missed was a simple example showing that the parse functions also accept unknown schemes like opc.tcp:// for example. Thanks a lot for all your work on providing useful high quality libraries for everyone! Best Regards, Chris