良好的URI設計的一些基本原則
- 不要使用查詢參數來更改狀态。
- 不要使用大小寫混用的路勁除非有必要，最好的都是小寫字母。
- 不要使用實作特定的擴充你的URI（php，py，PL，等。）
- 不要讓你的URI有遠端過程調用（RPC）的缺陷
- 盡可能多地限制URI空間。
- 保持路徑段短
- 最好用/resource或者/resource/；同時為你沒有用到的路徑建立301重定向
- 使用查詢參數對于一個子資源的選擇；如分頁、搜尋查詢
- 不要在URL中填寫任何東西，應該放在HTTP頭或正文中去。
（注意：我沒有說“RESTful URI設計”；URI本質上是不透明的REST。）
HTTP方法選擇的11個基本原則：
- 永遠不要GET去改變狀态；這會讓Googlebot毀掉你的一天
- 不要用PUT，除非你要更新整個resource
- 不要用PUT，除非你可以一直合法的用GET在同一個URI上
- 不要用POST來檢索資訊，那是長效的并且可能被緩沖
- 不要執行一個操作是非幂等的PUT
- 盡可能使用get
- 當不确定使用PUT還是POST時，優先使用POST
- 要使用POST當你需要做一些類似RPC時
- 對類較大或層次的資源使用PUT
- 删除資源時，優先選擇DELETE而不是POST
- 在做計算之類的請求時，優先使用GET；除非你的INPUT很大，這是你可以考慮使用POST
Web服務中HTTP設計的一般原則：
- 不要将中繼資料放在body中，應該放在header中。
- 不要将中繼資料放在單獨的資源中，除非當包含中繼資料時會造成很大的開銷。
- 使用适當的狀态碼
- 201 Created指建立資源時；在發送響應時資源必須存在
- 202 Accepted指成功執行一個操作或異步建立資源
- 400 Bad Request指當有人用僞造的資料進行操作；應用程式可能是一個驗證錯誤；一般儲存為500的未捕獲的異常
- 401 Unauthorized指當某人通路您的API時，未提供必要的授權header或授權中的憑據無效時；如果您不希望通過授權header來進行憑證，則不要使用此響應代碼。
- 403 Forbidden指當某人惡意或未經授權的方式通路你的API時
- 405 Method Not Allowed指當本來必須用PUT，而有人卻POST時，等等
- 413 Request Entity Too Large指當某人試圖發送一個無法接收的大檔案時
- 418 I’m teapot 指當我試圖用茶壺沖泡咖啡時
- 盡可能使用緩存Headers
- ETag headers讓你很容易的将資源設定為哈希值
- Last-Modified向你表明，保留資源更新時的時間戳是一個好主意。
- Cathe-Control和Expires應該有一個合理的值。
- 盡一切可能執行請求中的緩存headers（If-None-Modified, If-Modified-Since）
- 使用重定向的時一定要有意義，但這應該是罕見的Web服務