作者：Tim Berners-Lee 爵士，URI、URL、HTTP、HTML 和万维网的发明者，现任 W3C 负责人。 文章写于1998年
什么样的 URI 被认为是“酷”？
一个不会改变的。
URI 是如何改变的？
URI 不会改变：人们会改变它们。
理论上，人们没有理由更改 URI（或停止支持文档），但实际上有数以百万计的原因。
理论上，域名称空间的名义所有者实际上拥有该域名称空间，因此也拥有其中的所有 URI。 除了破产之外，没有什么可以阻止域名所有者保留该名称。 而且从理论上讲，您的域名下的 URI 空间完全在您的控制之下，因此您可以随心所欲地使其稳定。 文档从互联网上消失的唯一充分理由几乎是拥有该域名的公司已经倒闭或无法再维持服务器运行。 那么世界上为什么会有那么多缺失的环节呢？ 其中一些只是缺乏深思熟虑。 您可能会听到以下一些原因：
我们刚刚重新组织了网站以使其变得更好。
您真的认为旧的 URI 不能再工作了吗？ 如果是这样，那么你选择它们就很糟糕。 考虑保留新的以供下次重新设计。
我们有太多的东西，以至于我们无法跟踪哪些内容已过时、哪些内容属于机密以及哪些内容仍然相关，因此我们认为最好将其全部关闭。
我只能表示同情。 W3C 经历了一段时期，我们必须在公开档案材料之前仔细筛选其机密性。 应该提前考虑好这个决定 - 确保在每个文档中记录可接受的读者群、创建日期，最好还记录到期日期。 保存此元数据。
好吧，我们发现我们需要移动文件......
这是最可悲的借口之一。 许多人不知道 Web 服务器允许您控制对象的 URI 与其在文件系统中的实际位置之间的关系。 将 URI 空间视为一个组织完美的抽象空间。 然后映射到你实际用来实现它的任何现实。 然后将此报告给网络服务器。 您甚至可以编写自己的服务器片段以使其正确。
约翰不再维护此文件，而简现在维护此文件。
URI 中是否有 John 的名字？ 不对，文件就在他的目录里吗？ 哦，那好吧。
以前我们使用 CGI 脚本来实现此目的，但现在我们使用二进制程序。
有一个疯狂的想法，即由脚本创建的页面应该位于“cgibin”或“cgi”区域。 这揭示了如何运行 Web 服务器的机制。 您更改了机制（即使在保存内容时），哎呀 - 您的所有 URI 都发生了变化。
以美国国家科学基金会（NSF）为例：
NSF 在线文件
http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl
开始查看文档的第一页显然在几年内不会保持不变。 cgi-bin, oldbrowse и pl - 所有这些都给出了有关我们现在如何做的一些信息。 如果您使用该页面来搜索文档，您得到的第一个结果同样糟糕：
密码学和编码理论工作组的报告
http://www.nsf.gov/cgi-bin/getpub?nsf9814
对于文档索引页，虽然html文档本身看起来要好得多：
http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm
这里 pubs/1998 标头将为任何未来的档案服务提供一个很好的线索，表明旧的 1998 文档分类方案仍然有效。 尽管 2098 年的文档编号可能会有所不同，但我想这个 URI 仍然有效，并且不会干扰 NSF 或任何其他维护档案的组织。
我不认为 URL 必须是持久的——有 URN。
这可能是 URN 辩论最严重的副作用之一。 有些人认为，由于对更永久的命名空间的研究，他们可能会不小心悬挂链接，因为“URN 将解决所有问题”。 如果你是这些人中的一员，那么让我让你失望吧。
我见过的大多数 URN 方案看起来都像一个权威标识符，后跟一个日期和一个您选择的字符串，或者只是一个您选择的字符串。 这与 HTTP URI 非常相似。 换句话说，如果您认为您的组织能够创建长期存在的 URN，那么现在就通过将它们用于您的 HTTP URI 来证明这一点。 HTTP 本身不会使您的 URI 变得不稳定。 只有您的组织。 创建一个将文档 URN 映射到当前文件名的数据库，并让 Web 服务器使用它来实际检索文件。
如果你已经到了这一步，如果你没有时间、金钱和人脉来开发一些软件，那么你可以说出以下借口：
我们想要，但我们只是没有合适的工具。
但你可以对此表示同情。 我完全同意。 您需要做的是强制 Web 服务器立即解析持久 URI，并返回文件当前存储在当前疯狂文件系统上的任何位置。 您希望将所有 URI 存储在文件中作为检查，并使数据库始终保持最新。 您希望保留同一文档的不同版本和翻译之间的关系，并维护独立的校验和记录以确保文件不会因意外错误而损坏。 Web 服务器根本不具备这些功能。 当您想要创建新文档时，编辑器会要求您指定 URI。
您需要能够在不更改 URI 的情况下更改 URI 空间中的所有权、文档访问权限、存档级别安全性等。
一切都太糟糕了。 但我们会纠正这种情况。 在 W3C，我们使用 Jigedit（Jigsaw 编辑服务器）功能来跟踪版本，并尝试文档生成脚本。 如果你开发工具、服务器、客户端，请注意这个问题！
这个借口也适用于许多 W3C 页面，包括这个页面：照我说的做，而不是照我做的做。
我为什么要在乎？
当您更改服务器上的 URI 时，您永远无法完全判断谁将拥有旧 URI 的链接。 这些可以是来自常规网页的链接。 为您的页面添加书签。 该 URI 可能被潦草地写在给朋友的信的页边空白处。
当有人点击链接但链接被破坏时，他们通常会失去对服务器所有者的信任。 由于无法实现自己的目标，他在情感上和身体上也感到沮丧。
很多人一直抱怨链接失效，我希望损害是显而易见的。 我希望文档消失的服务器维护者的声誉损失也是显而易见的。
所以我该怎么做？ 统一接口设计
分配2年、20年、200年可以使用的URI是网站管理员的责任。 这需要深思熟虑、组织和决心。
如果 URI 中的任何信息发生变化，则 URI 也会发生变化。 如何设计它们非常重要。 （什么，URI设计？我需要设计URI吗？是的，你应该考虑一下）。 设计基本上意味着忽略 URI 中的任何信息。
文档的创建日期（即 URI 的发布日期）是永远不会改变的。 它对于将使用新系统的查询与使用旧系统的查询分开非常有用。 这是从 URI 开始的好地方。 如果文档已注明日期，即使该文档将来会相关，那么这也是一个好的开始。
唯一的例外是故意使用“最新”版本的页面，例如对于整个组织或其中的大部分。
http://www.pathfinder.com/money/moneydaily/latest/
这是《金钱》杂志最新的《金钱日报》专栏。 此 URI 中不需要日期的主要原因是没有理由存储比日志寿命更长的 URI。 当Money消失时，Money Daily的概念也随之消失。 如果您希望链接到内容，您应该在档案中单独链接到它：
http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html
（看起来不错。假设“金钱”在 pathfinder.com 的整个生命周期中都意味着相同的事情。有重复的“98”和不必要的“.html”，但在其他方面看起来像是一个强 URI。
什么要放在一边
全部！ 除了创建日期之外，将任何信息放入 URI 中都会以某种方式带来麻烦。
- 作者姓名。 随着新版本的推出，作者身份可能会发生变化。 人们离开组织并将东西传递给其他人。
- 事情。 这个非常困难。 一开始看起来总是不错，但变化却出人意料地快。 我将在下面详细讨论这一点。
- 是否添加。 像“old”、“draft”等目录，更不用说“latest”和“cool”，出现在所有文件系统中。 文档更改状态 - 否则创建草稿就没有意义。 文档的最新版本需要一个持久标识符，无论其状态如何。 不要在名称中包含状态。
- 访问。 在 W3C，我们将网站分为员工、会员和公众三个部分。 这听起来不错，但当然，文件是从员工的团队想法开始的，经过与成员的讨论，然后成为公共知识。 如果每次打开文档进行更广泛的讨论时，所有旧链接都被破坏，那真是太遗憾了！ 现在我们继续讨论简单的日期代码。
- 文件扩展名。 这是一个很常见的现象。 “cgi”，甚至“.html”将来也会改变。 您可能在 20 年内不再使用此页面的 HTML，但今天的链接应该仍然有效。 W3C 站点上的规范链接不使用扩展名 ().
- 软件机制。 在 URI 中，查找“cgi”、“exec”以及其他“看看我们正在使用什么软件”的术语。 有人想用一生的时间来编写 Perl CGI 脚本吗？ 不？ 然后删除 .pl 扩展名。 请阅读服务器手册以了解如何执行此操作。
- 磁盘名称。 快点！ 但我见过这个。
所以我们网站上最好的例子就是
http://www.w3.org/1998/12/01/chairs
... W3C 主席会议记录报告。
主题和按主题分类
我将更详细地讨论这种危险，因为它是最难以避免的事情之一。 通常，当您按文档的工作对文档进行分类时，主题最终会出现在 URI 中。 但这种细分会随着时间的推移而改变。 区域的名称将会改变。 在 W3C，我们希望将 MarkUP 更改为 Markup，然后更改为 HTML，以反映该部分的实际内容。 此外，通常还有平面命名空间。 100年后，你确定你不想重复使用任何东西吗？ 例如，在我们短暂的一生中，我们已经想重用“历史”和“样式表”。
这是一种组织网站的诱人方式，也是组织任何事物（包括整个网络）的真正诱人的方式。 这是一个很好的中期解决方案，但从长远来看存在严重缺陷。
部分原因在于意义哲学。 语言中的每个术语都是聚类的潜在目标，每个人对其含义可能有不同的理解。 由于实体之间的关系更像是网络而不是树，因此即使那些同意网络的人也可能选择树的不同表示。 这些是我（经常重复的）对分层分类作为通用解决方案的危险的一般观察。
事实上，当您在 URI 中使用主题名称时，您就致力于某种分类。 也许将来您会更喜欢不同的选择。 URI 将容易受到侵犯。
使用主题区域作为 URI 的一部分的原因是，URI 空间的子部分的责任通常是委派的，然后您需要负责该子空间的组织机构的名称（部门、组或其他名称）。 这是绑定到组织结构的 URI。 通常只有当更远的（左侧）URI 受日期保护时才是安全的：1998/pics 对您的服务器来说可能意味着“我们在 1998 年对图片的含义”，而不是“在 1998 年我们对现在所谓的图片做了什么”。
不要忘记域名
请记住，这不仅适用于 URI 中的路径，还适用于服务器名称。 如果你有不同的服务器来处理不同的事情，请记住，在不破坏很多很多链接的情况下，这种划分是不可能改变的。 一些经典的“看看我们今天使用的软件”错误是域名“cgi.pathfinder.com”、“secure”、“lists.w3.org”。 它们旨在使服务器管理更加容易。 无论域名是否代表公司的一个部门、文档状态、访问级别或安全级别，在对多种文档类型使用多个域名之前都要非常非常小心。 请记住，您可以使用重定向和代理将多个 Web 服务器隐藏在单个可见 Web 服务器内。
哦，还要考虑一下您的域名。 在您改变产品线并停止生产肥皂后，您不希望被称为soap.com（对目前拥有soap.com 的人表示歉意）。
结论
将 URI 保存 2 年、20 年、200 年甚至 2000 年显然并不像看起来那么容易。 然而，在整个互联网上，网站管理员正在做出的决定使得这项任务对他们自己来说在未来变得非常困难。 通常这是因为他们使用的工具的作用是仅呈现当前最好的网站 - 并且没有人评估当一切发生变化时链接会发生什么。 然而，这里的要点是，很多很多事情都可以改变，而你的 URI 可以而且应该保持不变。 只有当您考虑如何创建它们时，这才有可能。
另见：
添置
如何删除文件扩展名...
...来自当前基于文件的 Web 服务器中的 URI？
例如，如果您使用 Apache，则可以将其配置为协商内容。 将文件扩展名（例如 .png）保存到文件（例如 我的狗.png），但您可以在没有它的情况下链接到网络资源。 然后，Apache 检查目录中是否有具有该名称和任何扩展名的所有文件，并可以从一组文件中选择最好的一个（例如，GIF 和 PNG）。 并且没有必要将不同类型的文件放在不同的目录中，事实上，如果这样做，内容匹配将不起作用。
- 设置您的服务器以协商内容
- 始终链接到不带扩展名的 URI
带有扩展名的链接仍然有效，但会阻止您的服务器选择当前和将来可用的最佳格式。
（实际上， mydog, mydog.png и mydog.gif — 有效的网络资源， mydog 是通用内容类型资源，并且 mydog.png и mydog.gif — 特定内容类型的资源）。
当然，如果您正在编写自己的 Web 服务器，那么使用数据库将持久标识符绑定到其当前形式是一个好主意，但要注意数据库的无限增长。
耻辱委员会 - 故事 1：第 7 频道
1999 年期间，我在页面上追踪了因下雪导致学校关闭的情况 http://www.whdh.com/stormforce/closings.shtml。 不要等待信息出现在电视屏幕底部！ 我从我的主页链接到它。 2000 年的第一场大暴风雪来了，我查看了页面。 那里写着:,
- 作为。
目前什么都没有关闭。 如遇天气警告，请返回。
不可能有这么大的风暴。 有趣的是日期不见了。 但如果你进入该网站的主页，将会有一个大按钮“Closed Schools”，这会导致该页面 http://www.whdh.com/stormforce/ 有一长串关闭学校的名单。
也许他们更改了获取列表的系统 - 但他们不需要更改 URI。
耻辱委员会 - 故事 2：Microsoft Netmeeting
随着对互联网的依赖日益增加，一个聪明的想法出现了，即可以将制造商网站的链接嵌入到应用程序中。 这已被多次使用和滥用，但您无法更改 URL。 就在前几天，我在帮助/Microsoft on the Web/Free stuff 菜单中尝试了来自 Microsoft Netmeeting 2/something 客户端的链接，收到了 404 错误 - 未找到来自服务器的响应。 也许已经确定了...
©1998
历史注释：在 20 世纪末，当本文写作时，“酷”是一个被认可的绰号，尤其是在年轻人中，表示时尚、品质或合适。 仓促间，URI 路径通常被选择是为了“酷”，而不是实用性或耐用性。 这篇文章试图重新引导人们追求酷的能量。
来源： habr.com