作者：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 路徑通常被選擇是為了“酷”，而不是實用性或耐用性。 這篇文章試圖重新引導人們追求酷的能量。
來源： www.habr.com