[paxys]

The web has evolved well beyond what it was envisioned to be at the time this was written - a collection of hyperlinked documents.

The reason for the eventual demise of the URL will simply be the fact that the concept of "resource" will just not be sufficient enough to describe every future class of application or abstract behavior that the web will enable.

[CaptArmchair]

I disagree.

It depends on how you define a "resource" and what which value you attribute to that resource. And this is exactly the crux: this is out of the scope of the specification. It's entirely left to those who implement URI's within a specific knowledge domain or problem domain to define what a resource is.

Far more important then "resource" is the "identifier" part. URI's are above all a convention which allows for minting globally unique identifiers that can be used to reference and dereference "resources" whatever those might be.

It's perfectly valid to use URI's that reference perishable resources that only have a limited use. The big difficulty is in appreciating resources and deriving how much need there is to focus on persistence and longevity. Cool URI's are excellent for referencing research (papers, articles,...), or identifying core concepts in domain specific taxonomies, or natural/cultural objects, or endorsement of information as an authority,...

The fallacy, then, is reducing URI's to how the general understanding of how the Web works: the simple URL you type in the address bar which allows you to retrieve and display that particular page. If Google et al. end up stripping URL's from user interfaces, and making people believe that you don't need URI's, inevitably a different identifier scheme and a new conceptual framework will need to be developed to just to be able to do what the Web is all about today: naming and referencing discrete pieces of information.

Ironically, you will find that such a framework and naming scheme will bear a big resemblances, and solves the same basic problems the Web has been solving for the past 30 years. And down the line, you will discover the same basic problem Cool URI's are solving today: that names and identifiers can change or become deprecated as our understanding and appreciation about information changes.

[scoutt]

I don't think it has evolved. I feel that it became more like a hack, on top of a hack, on top of another hack, and so on.

In the late 90's - early 2000's, HTML started to being pushed into fields that, at my opinion, were unrelated (remember active desktop?). Before you had time to react, HTML was being used to pass data between applications. At the time I was already doing embedded stuff and I remember being astonished to learn that I have to code an HTML parser/server/stack in my small 16-bit micro because some jerk thought it was a good idea to pass an integer using HTML (SOAP, for example).

In the meantime, HTML was being dynamically generated, and then dynamically modified in the browser, and then modified back in the server using the same thing you use to modify it in the browser. It's a snowball that will implode, sooner or later.

[082349872349872]

"a hack, on top of a hack, on top of another hack, and so on" is evolution.

My HN username may be a case in point, drawing from a selection of twice five[0] digits due to legacy code of Hox genes: https://pubmed.ncbi.nlm.nih.gov/1363084/

[0] "This new art is called the algorismus, in which / out of these twice five figures / 0 9 8 7 6 5 4 3 2 1, / of the Indians we derive such benefit"

https://upload.wikimedia.org/wikipedia/commons/thumb/3/35/Ca...

[scoutt]

You might see the Homer Simpson Car[0] and call it evolution too. But what I see is a mess, described as a sequence of hacks and bad decisions, just like HTML (and web stuff) today.

[0] https://www.wired.com/2014/07/homer-simpson-car/

[xboxnolifes]

Homer Simpsons car did not evolve at all. It was designed all in a single iteration.

[kanox]

SOAP is XML not HTML, unless I'm missing something.

I'm happy that the world moved on to the point that json/yaml-like formats are strongly preferred.

[scoutt]

Correct. I wanted to say "pass an integer over HTTP (SOAP, for example)". An XML to pass some value, all over HTTP, ~20 years ago.

[niftich]

The web has evolved because:

(1) some operators only care about a handful of the URLs under their domain;

(2) hardly anyone uses link relations, so most links are devoid of semantic metadata and are essentially context-free, requiring a human to read the page and try to guess the purpose of the link;

(3) so many 'resources' are now entire applications, and the operators of these applications sometimes find it undesirable to encode application state into the URI, so for these you can only get to the entry point -- everything else is ephemeral state inside the browser's script context.

But I disagree with the statement that "the reason for the eventual demise of the URL will simply be the fact that the concept of 'resource' will just not be sufficient enough to describe every future class of application or abstract behavior that the web will enable."

URIs are a sufficient abstraction to accomodate any future use-case. It's a string where the part before the first colon tells you how to interpret the rest of it. It'd be hard to get more generic, yet more expressive.

The demise of URLs, if it ever comes to pass, will be due to politics or fashion: e.g. browser vendors not implementing support for certain schemes, lack of interoperability around length limits, concerns about readability and gleanability, and vertical integration around content discovery.

[bandrami]

The web has evolved well below what it was envisioned to be 20 years ago. I can't think of a single Web-based activity I do that is not a significantly worse experience now than it was in the past.