對于URL,大家都比較熟悉，其他兩個詞就比較陌生了。URI、URL和URN是識別、定位和命名互聯網上的資源的標準途徑。1989年Tim Berners-Lee發明了互聯網（World Wide Web）。WWW被認為是全球互連的實際的和抽象的資源的集合–它按需求提供信息實體–通過互聯網訪問。實際的資源的范圍從文件到人，抽象的資源包括數據庫查詢。

因為要通過多樣的方式識別資源（人的名字可能相同，然而計算機文件只能通過唯一的路徑名稱組合訪問），所以需要標準的識別WWW資源的途徑。為了滿足這種需要，Tim Berners-Lee引入了標準的識別、定位和命名的途徑：URI、URL和URN。

URI：Uniform Resource Identifier，統一資源標識符；

URL：Uniform Resource Locator，統一資源定位符；

URN：Uniform Resource Name，統一資源名稱。

在這個體系中的URI、URL和URN是彼此關聯的。URI的范疇位于體系的頂層，URL和URN的范疇位于體系的底層。這種排列顯示URL和URN都是URI的子范疇。

三者中，其中URL和URI特別容易混淆。

URL是Internet上用來描述信息資源的字符串，主要用在各種WWW客戶程序和服務器程序上。采用URL可以用一種統一的格式來描述各種信息資源，包括文件、服務器的地址和目錄等。

URL的格式由下列三部分組成：

協議（或稱為服務方式）；

存有該資源的主機IP地址（有時也包括端口號）；

主機資源的具體地址。如目錄和文件名等。

第一部分和第二部分之間用”：//”符號隔開，第二部分和第三部分用”/”符號隔開。第一部分和第二部分是不可缺少的，第三部分有時可以省略。

目前最大的缺點是當信息資源的存放地點發生變化時，必須對URL作相應的改變。因此人們正在研究新的信息資源表示方法。

URI是以某種統一的（標準化的）方式標識資源的簡單字符串，一般由三部分組成：

訪問資源的命名機制。

存放資源的主機名。

資源自身的名稱，由路徑表示。

典型情況下，這種字符串以scheme開頭，語法如下：

[scheme:] scheme-specific-part

http://www.google.com，其中http是scheme，//www.google.com是 scheme-specific-part，并且它的scheme與scheme-specific-part被冒號分開了。

有的URI指向一個資源的內部。這種URI以”#”結束，并跟著一個anchor標志符（稱為片斷標志符）。

相對URI不包含任何命名規范信息。它的路徑通常指同一臺機器上的資源。相對URI可能含有相對路徑（如：“..”表示上一層路徑），還可以包含片斷標志符。

URI的常見問題

難以輸入，URI不必要的冗長。

莫明其妙的大寫字母。

不常見的標點符號。

在紙介質上顯示很困難，一些字符在紙上打印出來不容易辨認。

主機和端口的問題除了?scheme-specific?部分，domain?和port?也可能給用戶帶來困惑。

設計URI應該遵循的規則（具體還可以參考上一篇：優秀的URI不會改變）

URI?是網站UI的一部分，因此，可用的網站應該滿足這些URL?要求

簡單，好記的域名

簡短（short）的URI

容易錄入的URI

URI?能反應站點的結構

URI?是可以被用戶猜測和hack的（也鼓勵用戶如此）

永久鏈接，Cool URI don’t change

聰明的選擇URI

一定要短為了URI能被方便的錄入，寫下，拼寫和記憶，URI?要盡可能的短，根據w3c?提供的參考數據，一個URI?的長度最好不要超過80個字節（這并非一個技術限制，經驗和統計提供的數據），包括schema?和host,port?等。

大小寫策略URI的大小寫策略要適當，要么全部小寫，要么首字母大寫，應避免混亂的大小寫組合，在Unix?世界，文件路徑隊大小寫是敏感的，而在Windows?世界，則不對大小寫敏感。

允許URI管理URI映射?管理員可以重新組織服務器上的文件系統結構，而無需改動URI，這就需要URI和真實的服務器文件系統結構之間有一個映射機制。，而不是生硬的對應。這種映射機制可以通過如下技術手段實現：

Aliases?，別名，Apache?上的目錄別名，IIS?上的虛擬目錄

Symbolic links?，符號鏈接，Unix?世界的符號鏈接

Table or database of mappings?，數據庫映射，URI?和文件系統結構的對應關系存儲在數據庫中。

標準的重定向管理員可以簡單的通過修改HTTP?狀態代碼來實現服務器文件系統結構變更之后的URI兼容，可以利用的HTTP Status Code?有：

301 Moved Permanently ([RFC2616] section 10.3.2)

302 Found (undefined redirect scheme, [RFC2616] Section 10.3.3)

Temporary Redirect ([RFC2616] Section 10.3.8)

用獨立的URI

技術無關的URI

提供動態內容服務時，應使用技術無關的URI。即URI不暴露服務器端使用的腳本語言，平臺引擎，而這些語言，平臺，引擎的變化也不會導致URI的變更。因此，sevelet,cgi-bin之類的單詞不應該出現在URI?中。

提供靜態內容服務時，應當隱去文件的擴展名取而代之的技術是content-negotiation, proxy,?和URI mapping

身份標志和Session?機制

使用標準的身份認證機制，而不是每個用戶一個特定的URI

使用標準的Session?機制，而不是把Session ID?放在URI?中使用。

內容變更時使用標準轉向

對變更的內容使用標準的重定向

對刪除的資源使用 HTTP410

提供索引代理

索引策略

Content-Location

Content-MD5

提供適當的緩存信息

緩存相關的HTTP頭

緩存策略

緩存生成內容?HTTP HEAD和HTTP GET

總結

URI?是Web UI?的一部分，應當像對待網站Logo?和公司品牌一樣對待它

URI?是網站和普通用戶之間的唯一接口，應當像對待你的商務電話號碼一樣對待它

讀懂并記住上面兩句話，你下次設計URI?的時候就會給它應有的重視了。

URL?應當是用戶友好的

URI?應當是可讀的

URI?應當是可預測的

URI?應當是統一的

讀懂和記住上面四句話，你就知道應該設計什么樣的URI了。

歡迎關注我的公眾號（同步更新文章）：DoNet技術分享平臺

閱讀原文