酷URI不会改变
Cool URIs don\'t change文章的google翻译，作者用了好多我不认识的词汇，唉，自己墨水太少了
什么是一个很酷的URI？
一个很酷的URI是一个不会改变的URI。
什么样的URI改变了？
URI不会改变：人们才能改变它们.
理论上人们根本没有理由改变URI（或停止维护文档），但实际上有数百万个理由。
理论上，域名空间所有者拥有域名空间，因此拥有其中的所有URI。除破产外，没有什么能阻止域名所有者保留名称。理论上，域名下的URI空间完全在您的控制之下，因此您可以根据需要使其稳定。文档从Web上消失的唯一好处是，拥有域名的公司已经停业或者无法再让服务器保持运行。那为什么世界上有那么多悬空链接呢？部分原因是缺乏深谋远虑。以下是您听到的一些原因：
我们刚刚重组了我们的网站以使其更好。
你真的觉得旧的URI不能继续运行吗？如果是这样，你选择它们非常糟糕。想想你的新产品，这样你就可以在下次重新设计后继续运行。
我们有太多的材料，我们无法跟踪什么是过时的，什么是保密的，什么是有效的，所以我们认为我们最好只是关闭整个批次。
我可以同情--W3C经历了这样一个时期，当我们在将档案公开之前必须仔细筛选档案材料以保密。解决方案是预先考虑的 - 确保您在每个文档中捕获其可接受的分布，创建日期和理想的到期日期。保留此元数据。
好吧，我们发现我们必须移动文件......
这是最蹩脚的借口之一。很多人不知道像Apache这样的服务器可以让你对对象的URI和代表它的文件实际位于文件系统中的灵活关系进行大量控制。将URI空间视为抽象空间，完美组织。然后，映射到实际用于实现它的任何现实。然后，告诉您的服务器。您甚至可以编写服务器的一些内容以使其正确。
Jane没有再保留该文件。
无论那个URI用John的名字做什么呢？它在他的目录中？我懂了。
我们过去常常使用cgi脚本，现在我们使用二进制程序。
有一个疯狂的概念，脚本生成的页面必须位于“cgibin”或“cgi”区域。这暴露了您运行服务器的机制。您更改机制（甚至保持内容相同）和哎呀 - 您的所有URI都会更改。
例如，参加国家科学基金会：
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方案看起来都像是一个权限ID，后面跟着你选择的日期和字符串，或者只是你选择的字符串。这看起来非常像HTTP URI。换句话说，如果您认为您的组织将能够创建将持续的URN，那么现在就通过这样做并将它们用于您的HTTP URI来证明它。没有什么关于HTTP会使您的URI不稳定。这是你的组织。创建一个将文档URN映射到当前文件名的数据库，让Web服务器使用它来实际检索文件。
如果你已经达到了这一点，那么除非你有时间，金钱和联系人来完成一些软件设计，否则你可以声称下一个借口：
我们想，但我们没有合适的工具。
现在这是我可以同情的一个。我完全同意。您需要做的是让Web服务器立即查找持久性URI并返回该文件，无论您当前的疯狂文件系统将其存储在何处。您希望能够将URI作为检查存储在文件中，并始终使数据库与实际情况保持一致。您希望存储不同版本和同一文档的翻译之间的关系，并且您希望保留校验和的独立记录，以防止意外错误导致文件损坏。并且Web服务器不具备这些功能。当您想要创建新文档时，编辑器会要求您提供URI而不是告诉您。
您需要能够在不更改URI的情况下更改URI空间中文档的所有权，访问权限，存档级别安全级别等内容。
太糟糕了。但我们会到达那里。在W3C，我们使用Jigedit功能（用于编辑的Jigsaw服务器）来跟踪版本，我们正在试验文档创建脚本。如果您制作工具，服务器和客户端，请注意！
这是一个突出的原因，例如适用于许多W3C页面，包括这个：所以我说的，不是我做的。
我为什么要在乎？
当您更改服务器上的URI时，您永远无法完全确定谁将拥有指向旧URI的链接。他们可能已经从常规网页建立了链接。他们可能已经为您的页面添加了书签他们可能在给朋友的一封信的边缘写了一个URI。
当有人关注链接并且它中断时，他们通常会对服务器的所有者失去信心。他们也感到沮丧 - 在情感上和实际上都是为了实现自己的目标。
足够的人总是抱怨悬挂链接，我希望损坏是显而易见的。我希望很明显声誉损坏是文件消失的服务器的维护者。
所以我该怎么做？设计URI
网站管理员有责任分配URI，您可以在2年内，20年内，200年内保留这些URI。这需要思想，组织和承诺。
当URI中的某些信息发生变化时，URI会发生变化。如何设计它们至关重要。 （什么，设计一个URI？我必须设计URI？是的，你必须考虑它。）。设计主要是指将信息留出来。
文档的创建日期 - 发布URI的日期 - 是一件不会改变的事情。它对于将使用新系统的请求与使用旧系统的请求分开非常有用。这是启动URI的一个好处。如果一份文件以任何方式过时，即使它几代人都会感兴趣，那么这个日期是一个很好的起点。
唯一的例外是一个故意为“最新”页面的页面，例如整个组织或其中的大部分。
http://www.pathfinder.com/money/moneydaily/latest/
是“Money”杂志中最新的“Money daily”专栏。在这个URI中不需要日期的主要原因是没有理由让URI的持久性超过杂志。如果Money退出生产，“今天的钱”的概念就会消失。如果要链接到内容，您可以链接到它在归档中单独出现的位置
http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html
（看起来很好。假设“money”在pathfinder.com的整个生命周期中都意味着同样的事情。有一个重复的“98”和你不需要的“.html”，否则这看起来像一个强大的URI） 。
什么遗漏
一切！在创建日期之后，在名称中放置任何信息都会以某种方式遇到麻烦。
- 作者姓名 - 作者身份可能随新版本而变化。人们退出组织并处理事务。
- 学科。这很棘手。它总是看起来很好，但变化惊人的快。我将在下面讨论这个问题。
- 状态目录如“旧”和“草稿”等，更不用说“最新”和“酷”出现在整个文件系统中。文件改变状态 - 或者制作草稿没有意义。无论状态如何，文档的最新版本都需要持久标识符。将状态保留在名称之外。
- 访问。在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可以而且应该保持不变。他们只有在你考虑如何设计它们时才能做到。
也可以看看：
Jacob Nielsen的“Alertbox”对同一主题大肆宣扬
（回到服务器管理员的礼仪，到你的工作结构）
脚注
如何删除文件扩展名...
...来自我在基于文件的实用Web服务器中的URI？
如果您正在使用Apache，则可以将其设置为进行内容协商。您将文件扩展名（例如.png）保留在文件（例如mydog.png）上，但是在没有它的情况下引用Web资源。 Apache然后检查目录中所有具有该名称和任何扩展名的文件，并且它还可以从集合中选择最好的一个（例如GIF和PNG）。 （您不必将不同类型的文件放在不同的目录中，实际上如果您这样做，内容协商将不起作用。）
- 设置服务器以进行内容协商
- 始终引用不带扩展名的URI
具有扩展名的引用仍然有效，但不允许您的服务器选择当前可用和未来格式中的最佳格式。
（事实上，mydog，mydog.png和mydog.gif都是有效的网络资源.mydog是content-type-generic。mydog.png和mydog.gif是内容类型特定的。）
当然，如果您正在构建自己的服务器，那么使用数据库将持久标识符与其当前表单相关联是一个非常干净的想法 - 尽管要注意数据库的无限增长。
火焰大厅 - 故事1：第7频道
在1999年期间，http：//www.whdh.com/stormforce/closings.shtml是我发现的一个页面，记录了由于下雪造成的学校关闭。等待它们滚过电视屏幕底部的另一种方法！我在主页上放了一个指针。来到2000年的第一场大风暴，我查看页面。它说，
“关闭。
目前没有关闭的效果。天气保证时请回来查看“
不可能是这么大的风暴。有趣的是日期不见了。但是如果我去网站的主页，有一个大按钮“学校关闭”，它带我到http://www.whdh.com/stormforce/，其中有许多封闭学校的列表。
好吧，也许他们改变了从最终列表中获得结束的系统 - 但是他们不需要更改URI。
火焰大厅 - 故事2：微软Netmeeting
随着对Web越来越依赖的智能之一是应用程序可以将内置链接返回到制造商的网站。这已在很大程度上被使用和滥用，但是 - 你必须保持URL相同。就在前几天，我在微软Netmeeting 2 / something客户端的“Help / Microsoft on the Web / Free stuff”菜单下尝试了一个链接，得到了错误404 - 未找到来自服务器的响应。他们现在可能已修好了......
（c）1998 Tim BL
历史记录：在20世纪末编写本文时，“酷”是特别是年轻人的认可的绰号，表明趋势，质量或适当性。在急于涉及我们的DNS领域时，域名和URI路径的选择有时更多地指向明显的“冷静”而不是有用性或长寿。这个笔记试图重新定位追求冷静的能量。