The scheme breaks down in practice at the resource point, and even before then is a stretch in some cases. But at the resource point it's all over. There's no agreement about "mysql". And...
"Just because some libraries have chosen to create things that resemble URLs (such as MySQL, as you mentioned), does not mean that they are URLs as the term is descriptively, not prescriptively, defined."
As it turns out, that's a key part of the point I was making. This is why the original article is silly.
RDBMSes, of course, don't have hierarchically-organized "resources." That's the whole point of the "R" in there. However, the rest of the URL format still applies to them. The resource and query-parameter parts of the URL are indeed "a binary blob"—but that doesn't matter. Why?
The great thing about URLs, within a protocol like HTTP, is that they're discoverable—if the protocol associated with your schema guarantees some sort of non-destructive querying operation on a resource (ala a GET or HEAD operation), then you can retrieve the / resource of a server to get a sitemap, and use the further, hyperlinked URLs to find all of the site's resources in turn. You're supposed to treat the resource and query parameter parts of the URL as a binary blob; they're a token you give to the server to get other tokens.
URLs let you turn a your meaningless binary blob—a.k.a. a URN—into a (where to ask, what to ask for, who I am) triple. This is a useful thing, even if the "what to ask for" part is still opaque! It means that you can always dereference a URL starting from the Internet as a whole, whereas with a URN the "where to ask" part has to be figured out on your own. If you combine this with a discoverable protocol, you enable your URLs to be spidered and thus indexed—and then they can all be found and used by anyone who has a single graph edge pointing into your site. That's way better than, say, an ISBN number, isn't it?
"mailto" and "file" and those other ones you mentioned aren't URLs, as the term is commonly used. They are, in practce, URNs—they consist of a schema (namespace identifier) and an opaque blob. They don't decompose into a (where to ask, what to ask for, who I am) triple.
URLs are amazing, but to call something a URL, it has to already be uniform, and to decompose into one of those triples. So the original article was silly (see the sqlite3 example—that's a URN right there)—but at the same time correct. Use URLs to locate your resources. Just don't make something up and call it a URL; do the actual work of having a standard, uniform string that has a resource and a location in it. And if you don't have the weight to make your own standard and make everyone treat it as uniform? Use someone else's. Use HTTP, even! REST is basically people realizing HTTP guarantees nice things about URLs and taking advantage of that.
RDBMSes, of course, don't have hierarchically-organized "resources." That's the whole point of the "R" in there.
Databases contain schemas contain tables contain columns. The hierarchy is just fixed types and of limited depth.
And then there's S3, which names a resource but doesn't imply any hierarchy, since the namespace is actually flat, even though it looks like a hierarchical path with / as a separator.
Comments
The scheme breaks down in practice at the resource point, and even before then is a stretch in some cases. But at the resource point it's all over. There's no agreement about "mysql". And...
"Just because some libraries have chosen to create things that resemble URLs (such as MySQL, as you mentioned), does not mean that they are URLs as the term is descriptively, not prescriptively, defined."
As it turns out, that's a key part of the point I was making. This is why the original article is silly.
RDBMSes, of course, don't have hierarchically-organized "resources." That's the whole point of the "R" in there. However, the rest of the URL format still applies to them. The resource and query-parameter parts of the URL are indeed "a binary blob"—but that doesn't matter. Why?
The great thing about URLs, within a protocol like HTTP, is that they're discoverable—if the protocol associated with your schema guarantees some sort of non-destructive querying operation on a resource (ala a GET or HEAD operation), then you can retrieve the / resource of a server to get a sitemap, and use the further, hyperlinked URLs to find all of the site's resources in turn. You're supposed to treat the resource and query parameter parts of the URL as a binary blob; they're a token you give to the server to get other tokens.
URLs let you turn a your meaningless binary blob—a.k.a. a URN—into a (where to ask, what to ask for, who I am) triple. This is a useful thing, even if the "what to ask for" part is still opaque! It means that you can always dereference a URL starting from the Internet as a whole, whereas with a URN the "where to ask" part has to be figured out on your own. If you combine this with a discoverable protocol, you enable your URLs to be spidered and thus indexed—and then they can all be found and used by anyone who has a single graph edge pointing into your site. That's way better than, say, an ISBN number, isn't it?
"mailto" and "file" and those other ones you mentioned aren't URLs, as the term is commonly used. They are, in practce, URNs—they consist of a schema (namespace identifier) and an opaque blob. They don't decompose into a (where to ask, what to ask for, who I am) triple.
URLs are amazing, but to call something a URL, it has to already be uniform, and to decompose into one of those triples. So the original article was silly (see the sqlite3 example—that's a URN right there)—but at the same time correct. Use URLs to locate your resources. Just don't make something up and call it a URL; do the actual work of having a standard, uniform string that has a resource and a location in it. And if you don't have the weight to make your own standard and make everyone treat it as uniform? Use someone else's. Use HTTP, even! REST is basically people realizing HTTP guarantees nice things about URLs and taking advantage of that.
RDBMSes, of course, don't have hierarchically-organized "resources." That's the whole point of the "R" in there.
Databases contain schemas contain tables contain columns. The hierarchy is just fixed types and of limited depth.
And then there's S3, which names a resource but doesn't imply any hierarchy, since the namespace is actually flat, even though it looks like a hierarchical path with / as a separator.