一、URL設計規範之Restful
（一）什麼是REST？
REST全稱是Representational State Transfer，中文意思是表述（編者注：通常譯為表徵）性狀態轉移。
（二）URI設計上的一些技巧
1.使用_或-來讓URI可讀性更好
2.使用/來表示資源的層級關係
3.使用?用來過濾資源
4.,或;可以用來表示同級資源的關係
（三）下面列出了GET，DELETE，PUT和POST的典型用法:
1.GET
- 安全且冪等
獲取表示
變更時獲取表示（快取） 200（OK） - 表示已在響應中發出
204（無內容） - 資源有空表示
301（Moved Permanently） - 資源的URI已被更新
303（See Other） - 其他（如，負載均衡）
304（not modified）- 資源未更改（快取）
400 （bad request）- 指代壞請求（如，引數錯誤）
404 （not found）- 資源不存在
406 （not acceptable）- 服務端不支援所需表示
500 （internal server error）- 通用錯誤響應
503 （Service Unavailable）- 服務端當前無法處理請求2.POST
不安全且不冪等
使用服務端管理的（自動產生）的例項號建立資源
建立子資源
部分更新資源
如果沒有被修改，則不過更新資源（樂觀鎖）200（OK）- 如果現有資源已被更改
201（created）- 如果新資源被建立
202（accepted）- 已接受處理請求但尚未完成（非同步處理）
301（Moved Permanently）- 資源的URI被更新
303（See Other）- 其他（如，負載均衡）
400（bad request）- 指代壞請求
404 （not found）- 資源不存在
406 （not acceptable）- 服務端不支援所需表示
409 （conflict）- 通用衝突
412 （Precondition Failed）- 前置條件失敗（如執行條件更新時的衝突）
415 （unsupported media type）- 接受到的表示不受支援
500 （internal server error）- 通用錯誤響應
503 （Service Unavailable）- 服務當前無法處理請求3.PUT
不安全但冪等
用客戶端管理的例項號建立一個資源
通過替換的方式更新資源
如果未被修改，則更新資源（樂觀鎖）200 （OK）- 如果已存在資源被更改
201 （created）- 如果新資源被建立
301（Moved Permanently）- 資源的URI已更改
303 （See Other）- 其他（如，負載均衡）
400 （bad request）- 指代壞請求
404 （not found）- 資源不存在
406 （not acceptable）- 服務端不支援所需表示
409 （conflict）- 通用衝突
412 （Precondition Failed）- 前置條件失敗（如執行條件更新時的衝突）
415 （unsupported media type）- 接受到的表示不受支援
500 （internal server error）- 通用錯誤響應
503 （Service Unavailable）- 服務當前無法處理請求4.DELETE
不安全但冪等
刪除資源200 （OK）- 資源已被刪除
301 （Moved Permanently）- 資源的URI已更改
303 （See Other）- 其他，如負載均衡
400 （bad request）- 指代壞請求
404 （not found）- 資源不存在
409 （conflict）- 通用衝突
500 （internal server error）- 通用錯誤響應
503 （Service Unavailable）- 服務端當前無法處理請求
（四）URL設計常見問題
1.POST和PUT用於建立資源時有什麼區別?
POST和PUT在建立資源的區別在於，所建立的資源的名稱(URI)是否由客戶端決定。 例如為我的博文增加一個java的分類，生成的路徑就是分類名/categories/java，那麼就可以採用PUT方法。不過很多人直接把POST、GET、PUT、DELETE直接對應上CRUD，例如在一個典型的rails實現的RESTful應用中就是這麼做的。 我認為，這是因為rails預設使用服務端生成的ID作為URI的緣故，而不少人就是通過rails實踐REST的，所以很容易造成這種誤解。
2.客戶端不一定都支援這些HTTP方法吧?
的確有這種情況，特別是一些比較古老的基於瀏覽器的客戶端，只能支援GET和POST兩種方法。 在實踐上，客戶端和服務端都可能需要做一些妥協。例如rails框架就支援通過隱藏引數_method=DELETE來傳遞真實的請求方法， 而像Backbone這樣的客戶端MVC框架則允許傳遞_method傳輸和設定X-HTTP-Method-Override頭來規避這個問題。
3.統一資源介面對URI有什麼指導意義?（重點！！！！）
統一資源介面要求使用標準的HTTP方法對資源進行操作，所以URI只應該來表示資源的名稱，而不應該包括資源的操作。 通俗來說，URI不應該使用動作來描述。例如，下面是一些不符合統一介面要求的URI:
GET /getUser/1
POST /createUser
PUT /updateUser/1
DELETE /deleteUser/1
4.響應程式碼的處理有必要嗎?
HTTP的響應程式碼可用於應付不同場合，正確使用這些狀態程式碼意味著客戶端與伺服器可以在一個具備較豐富語義的層次上進行溝通。 例如，201（“Created”）響應程式碼表明已經建立了一個新的資源，其URI在Location響應報頭裡。 假如你不利用HTTP狀態程式碼豐富的應用語義，那麼你將錯失提高重用性、增強互操作性和提升鬆耦合性的機會。 如果這些所謂的RESTful應用必須通過響應實體才能給出錯誤資訊，那麼SOAP就是這樣的了，它就能夠滿足了。
總結：
（1）GET – 查詢操作
（2）POST – 新增、修改操作（非冪等操作）
（3）PUT – 修改操作（冪等操作）
（4）DELETE – 刪除操作url設計：/模組/資源/{標示}/集合1/…. （url可讀性比較好）
例：
/user/{uid}/frends ->好友列表
/user/{uid}/followes ->關注者列表。
/seckill/{uid}/excution ->秒殺某個產品
現階段，我理解Restful的核心就是最後一個放名詞！！！