URL的設計
你應該花一些時間來設計一下你的URL地址結構。在讀完本文之后,如果有一件事情是我希望你記住的話,那就是花一些時間來設計你的URL地址的結構。不要把它留給你的框架來決定,不要聽天由命,依賴運氣。要仔細地考慮,認真摸索出一種經驗。
URL的設計是一個很復雜的問題,我不能說有什么“正確”的解決方案——其挺類似于其他方面的設計的,有好的URL設計,有糟糕的URL設計,在這兩者之間的情況也個個不同——它是主觀的。
不過這并不意味著不存在用于創建出非常好的URL的最佳做法。我希望我這些年來學到的一些URL設計的最佳做法能夠給你留下深刻的印象,并且我會解釋為什么我認為使用新的HTML5?javascript的history?API來工作是一件很令人興奮的事情。
為什么需要對你的URL進行一番設計
URL欄已經成為了現代瀏覽器的一個主要吸引人的地方了,且它再也不僅是一個URL欄那么簡單——你可以輸入部分的URL,然后瀏覽器就像是會使用黑魔法似的召喚出了你正要查找的確切的完整地址。當我在我的URL欄中輸入了resque?issues時,得到的第一個結果是https://github.com/defunkt/resque/issues。
URL是全球統一的,它們可用在Chrome、Safari、Internet?Explorer、cURL、wget、你的iPhone、Android上,甚至會被寫在便簽上。它們就是web網絡的一種全球通用的語法。但是不要把這看成是理所當然的。
任何一個定期訪問你的網站的半技術化的用戶都應該能夠基于內存中的URL結構來瀏覽你的應用的90%部分。為了能夠實現這一點,你的URL必需是要注重實用性的,就幾乎仿佛它們就是數學方程式一樣——許多簡單的規則組合成一種策略性的方式,以此來獲得他們想要的頁面。
頂層的部分是最為重要的
URL最有價值的方面在于其頂層的部分。在我看來,在想法形成了之后,這就是接下來的任何啟動都應該最先要討論的事情,要遠在任何的技術討論之前,要遠在任何的代碼編寫之前。這一頂層部分將會改變形成你的網站功能的基礎。
我是不是有些夸張了?看起來可能會是這樣——但是以后會有1,000,000 個用戶,想想它會帶來多大的影響。想一下Facebook推出用戶名是多么重大的一件事??捎玫腢RL就像是不動產,而頂層的部分就是體現在外面的最好的資產。
另一個快速提示——每當你構建一個新的站點時,考慮一下這一組不實用的URL的黑名單列表(或許可從Quora的URL中了解到一點糟糕的URL設計)
命名空間是一種很棒的擴展URL的工具
命名空間可以作為一種很棒的建立實用的URL結構的方式,這種結構在后續的使用中很容易被記住。我在這里說的命名空間指的是什么?我的意思是,URL中指明了不同內容的那部分。一個例子:
https://github.com/defunkt/resque/issues
在上面的URL中,defunkt/resque 就是命名空間。為什么這會有用?這是因為在這一個URL之后的任何部分都突然變成了一個新的頂層部分,因此你可以去到任何的一個《user》/《repo》 , 然后加上/issues或者可能是/wiki,取得相同的頁面,但是是在不同的命名空間下。
保持命名空間的清晰,不要一開始就把一些內容放在/feature/《user》/《repo》下,一些放在/《user》/《repo》/feature下。對于命名空間來說,要發揮效用就必須是統一的。
查詢串是很棒的過濾和排序的手段
關于查詢串web有著一個混亂的過去,我見過各式各樣的事情,從每個網頁都使用同一個URL加上不同的查詢參數的網站,到一個查詢串參數都不用的網站,各種情況都有。
我喜歡把查詢串想象成URL的旋鈕——其調整你的當前視圖,把它按照你的喜好來進行微調,這就是為什么它們用在排序和過濾這些行為上會如此之棒。堅持一種統一的模式(比如說sort=alpha&dir=desc?),你就會把通過URL欄進行的排序和過濾變得簡單易記。
關于查詢串還有最后一件事情:在沒有附加查詢串的情況下,頁面應該是有效的,其可能給出的是一個不同的頁面,但沒有查詢串的URL應該是要呈現出頁面的。
英文網站的非ASCII?URL是很糟糕的
這個世界是一個復雜的地方,充滿著?üml?ts?, ?ê?yés!和各種令人畏懼的字符?。這些字符在任何英文網站的URL中都是不會有一席之地的。使用英文的鍵盤輸入這些字符很復雜,很多時候延展成瀏覽器中的一些混亂的字符(有在url中見過xn--n3h嗎?這是一個?)。
URL是為人設計的——而非為搜索引擎設計的
我是在這一行業中成長起來,學會了如何玩搜索引擎(好吧,就是Google)的把戲,以此來從我的聯盟營銷中賺錢。因此關鍵詞堆砌URL的做法對我來說并不陌生。像下面這樣來來結束一個URL的情況相當常見:
http://guitars.example.com/best-guitars/cheap-guitars/popular-guitar
就SEO的目的來說,使用這種URL的效果會很好,幸運的是,2003年Google的颶風式的更新消除了這類URL的任何排名優勢。遺憾的是,專業的SEO行業被強取豪奪給圍繞著,因此其可能還會建議你使用許多你盡可能想得到的關鍵字來堆砌你的URL
記住另外的一些要點:
1. 下劃線只有一個糟字可言,堅持使用破折號。
2. 使用短的、完整的并且是大家都知道的單詞。如果某個部分中有一個破折號或是一個特殊的字符的話,這個詞就有可能太長。
URL是提供給人用的,為使用的人設計它們。
URL是一種協議
URL是一種協議,在一個可預見的位置盡可能長久地供應某些東西。一旦你的首個訪問者點擊了URL,那么你就隱式地進入了這樣的一種協議中,即如果他們記住了來過該頁面或是點擊了刷新按鈕話,那么他要看到相同的東西。
在已經向公眾推出之后就不要再改變你的URL,如果你絕對有必要改變你的URL的話,加上重定向——這不那么會引起驚慌。
任何事物都應該有一個URL
在一個理想的環境中,你的網站上的任何一個單獨的屏幕顯示都應該得出一個URL,這一URL可被拷貝和粘貼來在另一個選項卡或是瀏覽器中再次產生相同的屏幕內容。公平地說,這并不是完全有可能的。除非是新近使用了一些新的HTML5瀏覽器的history?Javascript?API。值得注意的是,有兩個新的方法:
onReplaceState — 該方法代替了瀏覽器歷史中的當前URL,并讓后退(back)按鈕不受影響。
onPushState – 該方法把一個新的URL壓入到瀏覽器的歷史中,代替URL欄中的URL,并把它加入到瀏覽器的歷史棧中(影響到后退按鈕)。
何時使用onReplaceState?以及何時使用onPushState
這些新方法允許我們改變URL欄中的整個路徑,而不僅是錨元素。隨著這一新的強大功能而來的是一種新的設計責任——我們需要摸索出后退按鈕的使用經驗。
為了確定使用哪一個方法,問你自己這樣的一個問題:這一行為產生了新的內容呢?抑或是相同內容的不同顯示?
1. 產生了新的內容——你應該使用onPushState(例如:分頁鏈接)
2. 產生了相同內容的不同顯示——你應該使用onReplaceState(例如:排序和過濾)
使用你自己的判斷,不過這兩個規則應該會符合你80%的情況??紤]一下,當你點擊后退按鈕時,你希望看見什么,然后做到你所希望的。
鏈接的行為就應該像一個鏈接
諸如《a》和《button》之類的鏈接元素有著許多很棒的內建功能。如果你中鍵點擊或是命令點擊它們的話,它們會打開一個新的窗口。當你懸停在其之上時,你的瀏覽器會在狀態欄中告訴你它的URL地址。在用到onReplaceState和onPushState時,不要破壞了這一行為。
1. 把AJAX請求的位置嵌放在錨元素的href屬性中。
2. 在人們中鍵點擊或是命令點擊它們時,從Javascript的點擊處理程序中返回true值。
這是一個相當簡單的做法,在你的單擊處理程序內部使用一個快速的條件判斷。下面是一個jQuery兼容的例子片段:
$(‘a.ajaxylink’).click(function(e){
//?API?瀏覽器不支持history?API的后備
if?(!(‘replaceState’?in?window.history))?return?true
// 確保是中鍵的、控制的和命令的正常點擊行為
if?(e.which?== 2 ||?e.metaKey?||?e.ctrlKey){
return?true
}
// 做一些很棒的事情,然后改變URL
window.history.replaceState(null, “New?Title”, ‘/some/cool/url’)
return?false
})
特定于POST行為的URL需要廢除
在過去,開發社區很愛創建一些不能被再次使用的URL,我喜歡把它們稱為特定于POST行為(POST-specific)的URL——這是一些會在你提交了一個表單之后出現在你的地址欄中的URL,但是當你嘗試著拷貝和粘貼這些url到新的選項卡中時,你就會得到一個錯誤的地址。
這類UR完全沒有存在的借口,特定于Post行為的URL是用于重定向和API的——而非給最終用戶的。
一個很棒的例子
1. 用戶生成的URL部分只用ASCII字符(defunkt、resque)。
2. “pull”是“pull?request”的簡短版本——單個單詞,很容易關聯到來源詞。
3. 拉請求(pull?request)號局限的范圍為defunkt/resque?(此處是從1開始)。
4. 錨指向一個滾動位置,內容不會被擋住。
知識點精萃:URL還有許多不同的格式——找出patch和diff的版本看看。
一個時代的開始
我希望隨著新的Javascript?API的使用的增多,設計者和開發者會花一些時間來設計一下URL。這對于任何網站的可用性來說都是一個很重要的部分,但我卻見到太多忽略了這一點的URL了。盡管重新設計網站的外觀和感覺很容易,但重新設計URL的結構卻要難得多。
但我也很激動,這些年來我有觀察到URL的改變。有時是硬鏈接被犧牲在了AJAX這一祭壇上,有時是犧牲性能來為用戶生成真實的URL。最終我們會來到這樣的一個時間點上,到那時,我們既可以得到部分頁面渲染的性能和可用性優勢,同時又獲得設計有條理的和精煉的URL的經驗。
對這一帖子的內容有問題或是建議嗎?給我發郵件,拜托有禮貌一些 、講道理一些,我會回應的,也許甚至會張貼到本站點上。
想問我什么,發郵件到kneath+ask@gmail.com 就可以了。
來源:http://article.yeeyan.org/view/213582/200363
看不太懂呀,有點高深