URI和URL及URN的區別

      對於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的格式由下列三部分組成：

1. 協議（或稱爲服務方式）；
2. 存有該資源的主機IP地址（有時也包括端口號）；
3. 主機資源的具體地址。如目錄和文件名等。

　　第一部分和第二部分之間用」：//」符號隔開，第二部分和第三部分用」/」符號隔開。第一部分和第二部分是不可缺乏的，第三部分有時能夠省略。

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

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

1. 訪問資源的命名機制。
2. 存放資源的主機名。
3. 資源自身的名稱，由路徑表示。

　　典型狀況下，這種字符串以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了。