理解URI,URL,URN

標籤：root   移動互聯   綁定   Nid   很多   名稱   address   develop   必須   

在Web領域，我們常見三個專業詞彙URI,URL,URN，對於這三個詞我們或許知道其原意，其相互之間的關係，但對於URI,URN總有那麼一層朦朧感，因為URI是抽象的概念，而URN遠離現實開發有關。在這裡對這3個概念進行一些分析，試圖理清其內在邏輯。

首先需要瞭解IETF,RFC

在瞭解上述3個專業名詞前，我們需要先瞭解IETF和RFC，因為這兩者定義了UR*。IETF是國際互連網工程工作群組（The Internet Engineering Task Force），它是互連網技術標準化的國際民間組織。RFC是提交請求（Request For Comments），是一系列以編號排定的檔案。RFC文檔可分為三種：

• BCP Best Current Practice，最佳實務。
• FYI For Your Information，資訊文檔，僅供討論。
• STD Standard， 標準文檔。

IETF是定義URI,URL,URN的組織，RFC是定義URI,URL,URN的標準檔案。

參考：
RFC2026 https://datatracker.ietf.org/doc/rfc2026/
RFC wiki https://zh.wikipedia.org/wiki/RFC

URL

URL是統一資源定位器的縮寫，它對網路中的資源的定位提供了一種統一方案。它有如下的通用格式：

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<fragment>

URL是我們最常見，開發過程中也時時刻刻能接觸到的概念。也就是如上格式的表示網路資源的地址的字串。此外還有相對URL，這裡就不細述了。
類比於現實中的地址，URL就是Web中資源地址。

參考：
URL定義 RFC1738 https://www.w3.org/Addressing/rfc1738.txt
URL講解 URL與資源《HTML權威指南》第二章

URN

URN是統一資源名稱的縮寫，它對網路中的資源的名稱提供了一種統一方案。它要求全球唯一，並在資源不存在或不再可用時依然保持不變。它的格式如下：

"urn:" <NID> ":" <NSS>

URN基於這樣一種想法，網路中的URL是不會持久的，就像人可能搬家一樣，網路資源也可能被移動，導致URL失效。其基本思想是引入持久層URN，就像人一生基本不會改名，這樣就能避免URL的失效問題。URN採取某些策略實現URN與實際資源的映射，但這裡不用考慮。

20多年過去URN似乎並沒實用價值，這是很正常的，技術發展中很多技術標準都沉默於曆史中。但並不意味著其一定沒有價值，就像Web開發早期流行SOAP，後來迴歸到HTTP原始語義的RESTful。目前需要理解URN是因為其與URL,URI是綁定關係，因此必須知其所以然。我看來，URN沒被使用的原因在於：

• URN與URL是不相容的方案。
• 搜尋引擎、站內搜尋、移動互連網等出現，使用者不關心也記不住URL（URN也一樣）。URL是Web底層的基礎設施，進行改動成本很高，收益很低。
• URL的持久性沒有想象中那麼糟糕，合理的URL規劃能滿足URN所預期的功能。
• 使用者習慣URL，採用URN會導致學習成本。

總而言之，多年的實踐看來，URL並沒有想象中那麼差，URN也沒有想象中那麼好。

類比於現實中的人/機構的名稱，URN就是Web中的資源名稱。

參考：
URN討論：RFC1737 http://www.ietf.org/rfc/rfc1737.txt
URN文法：RFC2141 http://www.ietf.org/rfc/rfc2141.txt
URN曆史：《HTML權威指南》第二章 2.6 未來展望
分清 URI、URL 和 URN：https://www.ibm.com/developerworks/cn/xml/x-urlni.html#artrelatedtopics

URI

URI是統一資源標誌符的縮寫，它是對URL和URN的統一化抽象，URI為識別資源提供了一種簡單且可擴充的手段。在其定義看來，一個URI可以作為定位器、名稱或者兩者的結合。通用URI文法由方案(scheme)，權威(authority)，路徑(path)，查詢(query)和片段(fragment)組成：

      URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]      hier-part   = "//" authority path-abempty                  / path-absolute                  / path-rootless                  / path-empty

可以看到從文法層面上來講，URL與URI是存在一定的區別。關於文法區別的更多部分，可以詳細閱讀RFC文檔。
類比於顯示中的姓名、地址用來標誌人，URL、URN的本意也是用來標識資源，因此統一為URI。

參考：
URI討論：RFC1630 https://www.w3.org/Addressing/rfc1630.txt
URI文法：RFC3986 https://tools.ietf.org/html/rfc3986

使用URI還是URL？由於URN目前沒有實用價值，容易混淆的概念只在於URI和URL。作為應用開發人員的我們，對URI和URL的區別通常只在於命名，我的看法是：

• 根據API來命名，要什麼，給什麼。
• 在Web中通常需要的是具體的資源位置，因此一般使用URL

總結

本篇分析了URL,URN,URI的具體定義，他們的實際使用方式。標準在抽象、概念上很有意義，但實際開發中，往往看事實。

即使到本篇末尾，URL,URI,URN在我心仍然混亂的糾纏在一起，就像XML在我心中一樣，這與其定義之初就比較抽象，相關文檔也比較混亂有關。幸好實際使用並不需要太過糾結，除非涉及相關底層開發，瞭解到這個層次即可。

有些人會拿一些語言、庫對URI,URL的理解來作為對URI,URL的理解，我認為這種方式不太正確。語言和庫對URI,URL的理解可以看作其開發人員對RFC定義的相關概念的自我理解，具備一定的實踐價值，但本質還是二次知識。

理解URI,URL,URN