URL的設計

導讀：URL的設計是一個很複雜的問題，不能說有什麼「正確」的解決方案——其挺相似於其餘方面的設計的，有好的URL設計，有糟糕的URL設計，在這二者之間的狀況也不一樣——它是主觀的。不過這並不意味着不存在用於建立出很是好的URL的最佳作法。原文做者kneath總結了這些年來學到的一些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推出用戶名是多麼重大的一件事。可用的URL就像是不動產，而頂層的部分就是體如今外面的最好的資產。

另外一個快速提示——每當你構建一個新的站點時，考慮一下這一組不實用的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的經驗。