6 ms·

> There are no reasons at all in theory for people to change URIs (or stop maintaining documents), but millions of reasons in practice. I am not convinced that

by ketzu 5y ago

> There are no reasons at all in theory for people to change URIs (or stop maintaining documents), but millions of reasons in practice. I am not convinced that some of the reasons are not theoretical as well. The article in general seems very dismissive of the practical reasons to change URIs, like listing only the 'easily dismissable' ones to begin with. > The solution is forethought - make sure you capture with every document its acceptable distribution, its creation date and ideally its expiry date. Keep this metadata. What to do with an expired document? Don't get me wrong, it's good to strive for long lasting URIs and good design of URIs is important, but overall I believe a good archiving solution is a better approach. It keeps the current namespaces cleaner and easier to maintain. (Maintaining changes in URI philosophy and organization over tens to hundreds of years sounds like a maintenance nightmare.) The archiving solution should have browser support: If a URI can not be resolved as desired, it could notify the user of existing historic versions.

Symbiote 5y ago
An expired document can be removed, and a "410 Gone" response returned. This is clearer for the user, who can expect not to find the document elsewhere on the website.
kijin 5y ago
Many APIs use versioning to keep the current namespace clean while still supporting the old version. It goes like /v1/getPosts, /v2/post/get, etc. This might be argument in favor of preemptively adding another level of hierarchy to your URLs, so that when the time comes to move the entire site to a new backend, you can just proxy the entire /2019/ hierarchy to a compatibility layer. But who are we kidding, we live in a world where 12 months of support for a widely used framework is called "LTS". Nobody seems to care whether their domains will even resolve in 10 years.
- ketzu 5y ago
  > Many APIs use versioning to keep the current namespace clean while still supporting the old version. It goes like /v1/getPosts, /v2/post/get, etc. I think that is an important thing to do (as I agree desigining URIs is important!) I am just not sure it is reasonable, or even desireable, for them to be indefinately maintained. I am not sure what the right timeframe for deprecation would be either.
  - kijin 5y ago
    I don't think it would be feasible to maintain a fully functional copy of a dynamically generated page at the old URL for any length of time. That's just a recipe for security nightmare, not to mention the SEO penalty for duplicate content. 301/308 redirects, on the other hand, can be maintained more or less indefinitely as long as you keep around a mapping of old URLs to new URLs. If you need to change your URLs again, you just add more entries to the mapping database. Make your 404 handler look up this database first. One thing you can't do, though, is repurposing an existing URL. Hence the versioning. :)
  - giantrobot 5y ago
    URLs should be maintained even if the content is gone. At the very least you can give a useful HTTP return code, a permanent redirect or gone is more useful than a catch-all 404. You're either bridging old links to current links or telling visitors the old content has been removed.
eythian 5y ago
> The archiving solution should have browser support: If a URI can not be resolved as desired, it could notify the user of existing historic versions. If you use this add-on: https://addons.mozilla.org/nl/firefox/addon/wayback-machine_new/ https://addons.mozilla.org/nl/firefox/addon/wayback-machine_... it will pop up a box when it sees a 404 offering to search the wayback machine for older versions.
- dalmo3 5y ago
  Brave does it natively. It's surprising to see how many pages return 404 before redirecting to a live version.
- bmn__ 5y ago
  Better: https://addons.mozilla.org/firefox/addon/view-page-archive https://addons.mozilla.org/firefox/addon/view-page-archive
anoncake 5y ago
> (Maintaining changes in URI philosophy and organization over tens to hundreds of years sounds like a maintenance nightmare.) I can't see why. You maintain a table of redirects. When you change the URI organization, which would break the URIs, you add the appropriate redirects to prevent that. Then, when you change it again, you just append the new redirects without removing the old ones. If necessary, resolve redirect chains server-side. The table may grow large, but it doesn't seem much more complicated than maintaining redirects across just two generations. Am I missing something?

by ketzu 5y ago

Symbiote 5y ago

An expired document can be removed, and a "410 Gone" response returned. This is clearer for the user, who can expect not to find the document elsewhere on the website.

kijin 5y ago

Many APIs use versioning to keep the current namespace clean while still supporting the old version. It goes like /v1/getPosts, /v2/post/get, etc. This might be argument in favor of preemptively adding another level of hierarchy to your URLs, so that when the time comes to move the entire site to a new backend, you can just proxy the entire /2019/ hierarchy to a compatibility layer. But who are we kidding, we live in a world where 12 months of support for a widely used framework is called "LTS". Nobody seems to care whether their domains will even resolve in 10 years.

ketzu 5y ago
> Many APIs use versioning to keep the current namespace clean while still supporting the old version. It goes like /v1/getPosts, /v2/post/get, etc. I think that is an important thing to do (as I agree desigining URIs is important!) I am just not sure it is reasonable, or even desireable, for them to be indefinately maintained. I am not sure what the right timeframe for deprecation would be either.
- kijin 5y ago
  I don't think it would be feasible to maintain a fully functional copy of a dynamically generated page at the old URL for any length of time. That's just a recipe for security nightmare, not to mention the SEO penalty for duplicate content. 301/308 redirects, on the other hand, can be maintained more or less indefinitely as long as you keep around a mapping of old URLs to new URLs. If you need to change your URLs again, you just add more entries to the mapping database. Make your 404 handler look up this database first. One thing you can't do, though, is repurposing an existing URL. Hence the versioning. :)
- giantrobot 5y ago
  URLs should be maintained even if the content is gone. At the very least you can give a useful HTTP return code, a permanent redirect or gone is more useful than a catch-all 404. You're either bridging old links to current links or telling visitors the old content has been removed.

eythian 5y ago

> The archiving solution should have browser support: If a URI can not be resolved as desired, it could notify the user of existing historic versions. If you use this add-on: https://addons.mozilla.org/nl/firefox/addon/wayback-machine_new/ https://addons.mozilla.org/nl/firefox/addon/wayback-machine_... it will pop up a box when it sees a 404 offering to search the wayback machine for older versions.

dalmo3 5y ago
Brave does it natively. It's surprising to see how many pages return 404 before redirecting to a live version.
bmn__ 5y ago
Better: https://addons.mozilla.org/firefox/addon/view-page-archive https://addons.mozilla.org/firefox/addon/view-page-archive

anoncake 5y ago

> (Maintaining changes in URI philosophy and organization over tens to hundreds of years sounds like a maintenance nightmare.) I can't see why. You maintain a table of redirects. When you change the URI organization, which would break the URIs, you add the appropriate redirects to prevent that. Then, when you change it again, you just append the new redirects without removing the old ones. If necessary, resolve redirect chains server-side. The table may grow large, but it doesn't seem much more complicated than maintaining redirects across just two generations. Am I missing something?