介面的安全性主要圍繞 token、timestamp 和 sign 三個機制展開設計，保證介面的資料不會被篡改和重複呼叫，下面具體來看：
Token授權機制：
使用者使用使用者名稱密碼登入後伺服器給客戶端返回一個Token（通常是UUID），並將Token-UserId以鍵值對的形式存放在快取伺服器中。
服務端接收到請求後進行Token驗證，如果Token不存在，說明請求無效。Token是客戶端訪問服務端的憑證。
時間戳超時機制：
使用者每次請求都帶上當前時間的時間戳 timestamp，服務端接收到timestamp後跟當前時間進行比對，如果時間差大於一定時間（比如5分鐘），則認為該請求失效。
時間戳超時機制是防禦DOS攻擊的有效手段。
簽名機制：
將 Token 和 時間戳 加上其他請求引數再用MD5或SHA-1演算法（可根據情況加點鹽）加密，加密後的資料就是本次請求的簽名sign，服務端接收到請求後以同樣的演算法得到簽名，並跟當前的簽名進行比對，
如果不一樣，說明引數被更改過，直接返回錯誤標識。簽名機制保證了資料不會被篡改。
拒絕重複呼叫（非必須）：
客戶端第一次訪問時，將簽名sign存放到快取伺服器中，超時時間設定為跟時間戳的超時時間一致，二者時間一致可以保證無論在timestamp限定時間內還是外 URL都只能訪問一次。
如果有人使用同一個URL再次訪問，如果發現快取伺服器中已經存在了本次簽名，則拒絕服務。
如果在快取中的簽名失效的情況下，有人使用同一個URL再次訪問，則會被時間戳超時機制攔截。
這就是為什麼要求時間戳的超時時間要設定為跟時間戳的超時時間一致。拒絕重複呼叫機制確保URL被別人截獲了也無法使用（如抓取資料）。
流程如下：
1）：客戶端通過使用者名稱密碼登入伺服器並獲取Token
2）：客戶端生成時間戳timestamp，並將timestamp作為其中一個引數。
3）：客戶端將所有的引數，包括Token和timestamp按照自己的演算法進行排序加密得到簽名sign
4）：將token、timestamp和sign作為請求時必須攜帶的引數加在每個請求的URL後邊（http://api.com/users?token=asdsadasd×tamp=123&sign=123123123）
在以上三中機制的保護下：
如果有人劫持了請求，並對請求中的引數進行了修改，簽名就無法通過；
如果有人使用已經劫持的URL進行DOS攻擊，伺服器則會因為快取伺服器中已經存在簽名或時間戳超時而拒絕服務，所以DOS攻擊也是不可能的；
如果簽名演算法和使用者名稱密碼都暴露了，那齊天大聖來了估計也不好使吧。。。。
最後說一句，所有的安全措施都用上的話有時候難免太過複雜，在實際專案中需要根據自身情況作出裁剪，比如可以只使用簽名機制就可以保證資訊不會被篡改，或者定向提供服務的時候只用Token機制就可以了。
如何裁剪，全看專案實際情況和對介面安全性的要求~
待更新....