對于URL,大家都比較熟悉操软，其他兩個詞就比較陌生了缨伊。URI、URL和URN是識別伟葫、定位和命名互聯(lián)網(wǎng)上的資源的標(biāo)準(zhǔn)途徑。1989年Tim Berners-Lee發(fā)明了互聯(lián)網(wǎng)（World Wide Web）院促。WWW被認(rèn)為是全球互連的實際的和抽象的資源的集合–它按需求提供信息實體–通過互聯(lián)網(wǎng)訪問筏养。實際的資源的范圍從文件到人斧抱，抽象的資源包括數(shù)據(jù)庫查詢。
因為要通過多樣的方式識別資源（人的名字可能相同渐溶，然而計算機文件只能通過唯一的路徑名稱組合訪問）辉浦，所以需要標(biāo)準(zhǔn)的識別WWW資源的途徑。為了滿足這種需要茎辐，Tim Berners-Lee引入了標(biāo)準(zhǔn)的識別宪郊、定位和命名的途徑：URI、URL和URN拖陆。
URI：Uniform Resource Identifier弛槐，統(tǒng)一資源標(biāo)識符；
URL：Uniform Resource Locator慕蔚，統(tǒng)一資源定位符丐黄；
URN：Uniform Resource Name，統(tǒng)一資源名稱孔飒。
在這個體系中的URI、URL和URN是彼此關(guān)聯(lián)的艰争。URI的范疇位于體系的頂層坏瞄，URL和URN的范疇位于體系的底層。這種排列顯示URL和URN都是URI的子范疇甩卓。
三者中鸠匀，其中URL和URI特別容易混淆。
URL是Internet上用來描述信息資源的字符串逾柿，主要用在各種WWW客戶程序和服務(wù)器程序上缀棍。采用URL可以用一種統(tǒng)一的格式來描述各種信息資源，包括文件机错、服務(wù)器的地址和目錄等爬范。
URL的格式由下列三部分組成：
協(xié)議（或稱為服務(wù)方式）；
存有該資源的主機IP地址（有時也包括端口號）弱匪；
主機資源的具體地址青瀑。如目錄和文件名等。
第一部分和第二部分之間用”：//”符號隔開萧诫，第二部分和第三部分用”/”符號隔開斥难。第一部分和第二部分是不可缺少的，第三部分有時可以省略帘饶。
目前最大的缺點是當(dāng)信息資源的存放地點發(fā)生變化時哑诊，必須對URL作相應(yīng)的改變。因此人們正在研究新的信息資源表示方法及刻。
URI是以某種統(tǒng)一的（標(biāo)準(zhǔn)化的）方式標(biāo)識資源的簡單字符串镀裤，一般由三部分組成：
訪問資源的命名機制穷当。
存放資源的主機名。
資源自身的名稱淹禾，由路徑表示馁菜。
典型情況下，這種字符串以scheme開頭铃岔，語法如下：
[scheme:] scheme-specific-part
http://www.google.com汪疮，其中http是scheme，//www.google.com是 scheme-specific-part毁习，并且它的scheme與scheme-specific-part被冒號分開了智嚷。
有的URI指向一個資源的內(nèi)部。這種URI以”#”結(jié)束纺且，并跟著一個anchor標(biāo)志符（稱為片斷標(biāo)志符）盏道。
相對URI不包含任何命名規(guī)范信息。它的路徑通常指同一臺機器上的資源载碌。相對URI可能含有相對路徑（如：“..”表示上一層路徑）猜嘱，還可以包含片斷標(biāo)志符。
URI的常見問題
難以輸入嫁艇，URI不必要的冗長朗伶。
莫明其妙的大寫字母。
不常見的標(biāo)點符號步咪。
在紙介質(zhì)上顯示很困難论皆，一些字符在紙上打印出來不容易辨認(rèn)。
主機和端口的問題除了?scheme-specific?部分猾漫，domain?和port?也可能給用戶帶來困惑点晴。
設(shè)計URI應(yīng)該遵循的規(guī)則（具體還可以參考上一篇：優(yōu)秀的URI不會改變）
URI?是網(wǎng)站UI的一部分，因此悯周，可用的網(wǎng)站應(yīng)該滿足這些URL?要求
簡單粒督，好記的域名
簡短（short）的URI
容易錄入的URI
URI?能反應(yīng)站點的結(jié)構(gòu)
URI?是可以被用戶猜測和hack的（也鼓勵用戶如此）
永久鏈接，Cool URI don’t change
聰明的選擇URI
一定要短為了URI能被方便的錄入队橙，寫下坠陈，拼寫和記憶，URI?要盡可能的短捐康，根據(jù)w3c?提供的參考數(shù)據(jù)仇矾，一個URI?的長度最好不要超過80個字節(jié)（這并非一個技術(shù)限制，經(jīng)驗和統(tǒng)計提供的數(shù)據(jù)）解总，包括schema?和host,port?等贮匕。
大小寫策略URI的大小寫策略要適當(dāng)，要么全部小寫花枫，要么首字母大寫刻盐，應(yīng)避免混亂的大小寫組合掏膏，在Unix?世界，文件路徑隊大小寫是敏感的敦锌，而在Windows?世界馒疹，則不對大小寫敏感。
允許URI管理URI映射?管理員可以重新組織服務(wù)器上的文件系統(tǒng)結(jié)構(gòu)乙墙，而無需改動URI颖变，這就需要URI和真實的服務(wù)器文件系統(tǒng)結(jié)構(gòu)之間有一個映射機制。听想，而不是生硬的對應(yīng)腥刹。這種映射機制可以通過如下技術(shù)手段實現(xiàn)：
Aliases?，別名汉买，Apache?上的目錄別名衔峰，IIS?上的虛擬目錄
Symbolic links?，符號鏈接蛙粘，Unix?世界的符號鏈接
Table or database of mappings?垫卤，數(shù)據(jù)庫映射，URI?和文件系統(tǒng)結(jié)構(gòu)的對應(yīng)關(guān)系存儲在數(shù)據(jù)庫中组题。
標(biāo)準(zhǔn)的重定向管理員可以簡單的通過修改HTTP?狀態(tài)代碼來實現(xiàn)服務(wù)器文件系統(tǒng)結(jié)構(gòu)變更之后的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
技術(shù)無關(guān)的URI
提供動態(tài)內(nèi)容服務(wù)時，應(yīng)使用技術(shù)無關(guān)的URI崔列。即URI不暴露服務(wù)器端使用的腳本語言，平臺引擎旺遮，而這些語言赵讯，平臺，引擎的變化也不會導(dǎo)致URI的變更耿眉。因此边翼，sevelet,cgi-bin之類的單詞不應(yīng)該出現(xiàn)在URI?中。
提供靜態(tài)內(nèi)容服務(wù)時鸣剪，應(yīng)當(dāng)隱去文件的擴展名取而代之的技術(shù)是content-negotiation, proxy,?和URI mapping
身份標(biāo)志和Session?機制
使用標(biāo)準(zhǔn)的身份認(rèn)證機制组底，而不是每個用戶一個特定的URI
使用標(biāo)準(zhǔn)的Session?機制，而不是把Session ID?放在URI?中使用筐骇。
內(nèi)容變更時使用標(biāo)準(zhǔn)轉(zhuǎn)向
對變更的內(nèi)容使用標(biāo)準(zhǔn)的重定向
對刪除的資源使用 HTTP410
提供索引代理
索引策略
Content-Location
Content-MD5
提供適當(dāng)?shù)木彺嫘畔?/b>
緩存相關(guān)的HTTP頭
緩存策略
緩存生成內(nèi)容?HTTP HEAD和HTTP GET
總結(jié)
URI?是Web UI?的一部分债鸡，應(yīng)當(dāng)像對待網(wǎng)站Logo?和公司品牌一樣對待它
URI?是網(wǎng)站和普通用戶之間的唯一接口，應(yīng)當(dāng)像對待你的商務(wù)電話號碼一樣對待它
讀懂并記住上面兩句話铛纬，你下次設(shè)計URI?的時候就會給它應(yīng)有的重視了厌均。
URL?應(yīng)當(dāng)是用戶友好的
URI?應(yīng)當(dāng)是可讀的
URI?應(yīng)當(dāng)是可預(yù)測的
URI?應(yīng)當(dāng)是統(tǒng)一的
讀懂和記住上面四句話，你就知道應(yīng)該設(shè)計什么樣的URI了告唆。
歡迎關(guān)注我的公眾號（同步更新文章）：DoNet技術(shù)分享平臺
