On Tue, Jan 21, 2020 at 10:41 AM Andrey Semashev via Boost
There is a semantic difference between URI and URL - the former is an identifier and the latter is a locator (i.e. a path to a resource location). You can treat locator as an identifier but not the other way around. Using the term URL to refer to an URI is confusing.
Having both terms is confusing, and WhatWG got this right. The vast majority of users just want to "parse a URL", for example one that comes in from an HTTP request, or one that is specified on the command line. When they go into Google, they type "URL" they don't type "URI." Hardly anyone knows what a URI is. But even my mother who is 90 knows what a URL is. I want my libraries to be popular and have mass appeal, not just satisfy a niche audience of super-experts. When I type "URI" into Google I get: About 287,000,000 results (0.87 seconds) www.uri.edu The University of Rhode Island (top result) People Also Ask: What is difference URL and URI? While they are used interchangeably, there are some subtle differences... Now if I type "URL" into Google, I get: About 12,620,000,000 results (0.50 seconds) en.wikipedia.org › wiki › URL URL - Wikipedia (top result) People Also Ask: What is the URL? What is an example of a URL address? How do I find URL? What is the path in the URL? What is URL on my phone? What does WWW stand for? Yes, not only is "URL" 44 times more popular than "URI" in terms of search results, but the top question about "URI" is "What is difference URL and URI?". While for "URL" no one is asking about the difference. Another way to think of it, in terms of name recognition "URI" is to .org what "URL" is to .com. People assume that a domain name is in .com because that's the most popular TLD. That's why .com domains go for so much more money. It is true that URL is not an exact fit if you adhere to the technical documentation 100%, but I think the overall benefit of just standardizing on the name "URL" outweighs the downsides. It is easier for users, better for Boost, and gives the library more appeal to average folk.
The reason I'm interested particularly in URIs is because I have to deal with them, not so much with URLs.
This library should do everything you want with URIs since I take care of parsing all the top-level rules. The library does not make assumptions about the data. For example if you want to treat the path as just one string and ignore the segments, you can do that. If you want to ignore the distinction between username and password in the userinfo, you can do that too. You can treat the query params as an associative array of key/value pairs if you want, or you can ignore that and just work with the query directly. If you have specific use-cases feel free to open an issue or cite them here and I will make sure they are attended to (assuming it is in-scope). Thanks P.S. "Only snobs call it a URI" :)