[couchand]

> Filenames are just labels that we stick on a logical chunk of information. Implementation details can differ, but the concept itself is not going anywhere as long as humans like to put stable labels on mutable things.

This is the point that I think is completely lost on the author of the article, probably because of a focus on API design. It's a good thing that we can replace that dog-eared copy of Moby Dick with a shiny new one when the time comes, and our users don't need to change their URLs.

APIs are intended to be used primarily by machines, so it's fine for the URL structure to preference the predictable uniqueness of ids. However, for most URLs intended for use by humans, the forces are different.

A human-readable URL is not a pointer, it's a symlink.

[matt_kantor]

All good points, however one thing missing is that humans also want to be able to refer specifically to "that dog-eared copy of Moby Dick". Facts like "that dog-eared copy of Moby Dick is missing page 34" or "that dog-eared copy of Moby Dick is actually a super valuable early edition" should not change their referent when the library gets a shiny new copy of the book.

And that's exactly how I read the article: both mutable and immutable references are nice to have for different use cases.

[couchand]

Yes, that's true abstractly. However, A, those sorts of references are much less common in web pages than in physical descriptions (at least in my estimation) (though they're very common in APIs), and B, those repointable references are not the same as a search - I want to uniquely refer to the current value of this pointer, while allowing the publisher to relink as appropriate.

The article reads as universal URL design advice, but I'd argue the points only really apply to APIs.