URL設(shè)計原則和規(guī)范

去年秋天寫的一個文檔,花了我兩天時間.
轉(zhuǎn)載請注明出處,謝謝:)

URI設(shè)計原則和規(guī)范

什么是URI(URL)

定義

URI:Uniform Resource Locators

URL:UniformResource Identicators

URI分兩部分，scheme,scheme-specific，這兩部分由冒號分割開。schema包括HTTP,FTP,NEWS,GOPHER等，詳情參見RFC1738（ftp://ds.internic.net/rfc/rfc1738.txt）

語法

HTTP,FTP的語法很相像，都是這樣:

schema://user:password@host:port/directory/file.extension

編碼

URI中理論上只允許ASCII字符。

部分特殊符號必須編碼，不能直接出現(xiàn)在URI中，如“~”

Web項目中，這些都是URI：

鏈接地址（a標簽的href屬性）

圖片的源（img標簽的src屬性）

多媒體文件的源（object標簽的src屬性）

CSS，JavaScript地址（link標簽的href屬性，script標簽的src屬性）

為什么要設(shè)計好的URI

重要的入口

便于傳播

便于用戶挖掘內(nèi)容

URI的常見問題

難以輸入

URI不必要的冗長

比如：

http://www.bigcompany.com/PR/announcements/1994/dec/new-server-version.txt

這個還算好的，看看這個：http://www.globeandmail.com/servlet/ArticleNews/PEstory/TGAM/20020909/RVCRR/Business/business/business_temp/2/2/5/

莫明其妙的大寫字母

比如：

ftp://ftp.bigstate.edu/pub/docs/OnTBGHill.txt

不常見的標點符號

ftp://ftp.bigstate.edu/pub/docs/moon_3+manual

在紙介質(zhì)上顯示很困難

一些字符在紙上打印出來不容易辨認，例如

“～”（數(shù)字鍵1旁邊那個鍵）在不同的字體下面顯示不同，有時候在一行的頂部，有時候在底部。

“l”（字母L的小寫版本）和“1”（數(shù)字一）幾乎無法分辨——在紙介質(zhì)上的時候，同樣的還有“O”和“0”。

“`”太微小，以致于人們在某些情況下看不到它。

主機和端口的問題

除了 scheme-specific部分，domain和port也可能給用戶帶來困惑。

http://admin.bigstate.edu:8001/docs/thesis/jones

設(shè)計URI應(yīng)該遵循的原則

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的大小寫策略要適當，要么全部小寫，要么首字母大寫，應(yīng)避免混亂的大小寫組合，在Unix世界，文件路徑隊大小寫是敏感的，而在Windows世界，則不對大小寫敏感，所以，http://www.example.com/FOO和http://www.example.com/foo是兩個不同的URI（盡管他們在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上的虛擬目錄

Symboliclinks，符號鏈接，Unix世界的符號鏈接

Table or database ofmappings，數(shù)據(jù)庫映射，URI和文件系統(tǒng)結(jié)構(gòu)的對應(yīng)關(guān)系存儲在數(shù)據(jù)庫中

標準的重定向

管理員可以簡單的通過修改HTTP狀態(tài)代碼來實現(xiàn)服務(wù)器文件系統(tǒng)結(jié)構(gòu)變更之后的URI兼容，可以利用的HTTPStatus Code有：

301 Moved Permanently([RFC2616] section 10.3.2)

302 Found (undefined redirectscheme, [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ù)器端使用的腳本語言，平臺引擎，而這些語言，平臺，引擎的變化也不會導致URI的變更。因此，sevelet,cgi-bin之類的單詞不應(yīng)該出現(xiàn)在URI中。

• 提供靜態(tài)內(nèi)容服務(wù)時，應(yīng)當隱去文件的擴展名

  取而代之的技術(shù)是content-negotiation, proxy, 和URI mapping

身份標志和Session機制

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

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

  使用Tomcat和PHP3的站點容易犯這類錯誤，將Session ID放在URI中，實際上，他們應(yīng)當用HTTP Header來實現(xiàn)之。

內(nèi)容變更時使用標準轉(zhuǎn)向

對變更的內(nèi)容使用標準的重定向

對刪除的資源使用HTTP410

提供索引代理

索引策略

Content-Location

Content-MD5

提供適當?shù)木彺嫘畔?/h2>

緩存相關(guān)的HTTP頭

緩存策略

緩存生成內(nèi)容

HTTP HEAD和HTTPGET

總結(jié)

本文詳細描述了URI的定義和作用，揭示了目前Web開發(fā)中普遍存在的問題，并給出了URI設(shè)計原則和規(guī)范，希望本文的讀者能在開發(fā)和設(shè)計Web應(yīng)用程序的時候體會和運用這些知識。

• URI是Web UI的一部分，應(yīng)當像對待網(wǎng)站Logo和公司品牌一樣對待它

• URI是網(wǎng)站和普通用戶之間的唯一接口，應(yīng)當像對待你的商務(wù)電話號碼一樣對待它

讀懂并記住上面兩句話，你下次設(shè)計URI的時候就會給它應(yīng)有的重視了。

• URL應(yīng)當是用戶友好的

• URI應(yīng)當是可讀的

• URI應(yīng)當是可預(yù)測的

• URI應(yīng)當是統(tǒng)一的

讀懂和記住上面四句話，你就知道應(yīng)該設(shè)計什么樣的URI了。