3 ms·
Heh, you got me:) I agree the situation is more complicated than I described. My main response to this is: just because we can't always use content-addressable
by seagreen 10y ago
Heh, you got me:) I agree the situation is more complicated than I described.
My main response to this is: just because we can't always use content-addressable links doesn't mean we shouldn't use them where we can. I'm sure you see where I'm going with this. When pirate movie websites have a 1000x more rock-solid way of identifying content than the NY Times we have a problem.
But even in the most inhospitable situations like the one you describe we can still do better. Content-addressability won't help, agreed. How about promoting UUID style non-human readable paths instead? One of the reasons links change is that the content changes slightly and the name goes out of date. Perhaps in your case legal says "these prices may be up to ten minutes out of date, we can no longer call that path /prices/current/feed". If the path was /3824-3822-4864 this wouldn't be a problem. Information about what that endpoint returns can be placed in a description field or in the docs where it can be kept up-to-date without breaking links.
- zAy0LfpBZLC8mAC 10y agoI don't think that would make any real difference. Links break because people switch to new software that has different URIs for the content and they don't see the problem, or due to software that has stupid mechanisms for generating URIs, that's it. URIs changing due to a concious decision to change the URI are the rare exception, it's mostly just a side effect that noone cares about. Also, in your specific example, it would still be possible to replace the old content with a document explaining the change and linking to the new URI, or possibly even an HTTP redirect. Plus, a semantically meaningless name might still not prevent the problem, as there just as well could be legal consequences if you have communicated before that this URI provides "current prices" via some other means than the URI itself.