寫於2016-01-07
使用者用密碼登入成功後，伺服器返回token給客戶端；
客戶端將token儲存在本地，發起後續的相關請求時，將token發回給伺服器；
伺服器檢查token的有效性，有效則返回資料，若無效，分兩種情況：
token錯誤，這時需要使用者重新登入，獲取正確的token
token過期，這時客戶端需要再發起一次認證請求，獲取新的token
然而，此種驗證方式存在乙個安全性問題：當登入介面被劫持時，黑客就獲取到了使用者密碼和token，後續則可以對該使用者做任何事情了。使用者只有修改密碼才能奪回控制權。
我們目前的做法是給每個介面都新增簽名。給客戶端分配乙個金鑰，每次請求介面時，將金鑰和所有引數組合成源串，根據簽名演算法生成簽名值，傳送請求時將簽名一起傳送給伺服器驗證。類似的實現可參考oauth1.0的簽名演算法。這樣，黑客不知道金鑰，不知道簽名演算法，就算攔截到登入介面，後續請求也無法成功操作。不過，因為簽名演算法比較麻煩，而且容易出錯，只適合對內的介面。如果你們的介面屬於開放的api，則不太適合這種簽名認證的方式了，建議還是使用oauth2.0的認證機制。
不需要註冊，不需要修改密碼，也不需要因為忘記密碼而重置密碼的操作了；
使用者不再需要記住密碼了，也不怕密碼洩露的問題了；
相對於密碼登入其安全性明顯提高了。
介面的資料一般都採用json格式進行傳輸，不過，需要注意的是，json的值只有六種資料型別：
所以，傳輸的資料型別不能超過這六種資料型別。以前，我們曾經試過傳輸date型別，它會轉為類似於"2023年1月7日 09時17分42秒 gmt+08:00"這樣的字串，這在轉換時會產生問題，不同的解析庫解析方式可能不同，有的可能會轉亂，有的可能直接異常了。要避免出錯，必須做特殊處理，自己手動去做解析。為了**這種問題，最好的解決方案是用毫秒數表示日期。
伺服器返回的資料結構，一般為：
}code: 狀態碼，0表示成功，非0表示各種不同的錯誤
message: 描述資訊，成功時為"success"，錯誤時則是錯誤資訊
data: 成功時返回的資料，型別為物件或資料
不同錯誤需要定義不同的狀態碼，屬於客戶端的錯誤和服務端的錯誤也要區分，比如1xx表示客戶端的錯誤，2xx表示服務端的錯誤。這裡舉幾個例子：
0：成功
100：請求錯誤
102：缺少簽名
103：缺少引數
200：伺服器出錯
201：服務不可用
202：伺服器正在重啟
data欄位只在請求成功時才會有資料返回的。資料型別限定為物件或陣列，當請求需要的資料為單個物件時則傳回物件，當請求需要的資料是列表時，則為某個物件的陣列。這裡需要注意的就是，不要將data傳入字串或數字，即使請求需要的資料只有乙個，比如token，那返回的data應該為：
// 正確
data:
// 錯誤
data: 123456
介面不可能一成不變，在不停迭代中，總會發生變化。介面的變化一般會有幾種：
為了適應這些變化，必須得做介面版本的設計。實現上，一般有兩種做法：
每個介面有各自的版本，一般為介面新增個version的引數。
整個介面系統有統一的版本，一般在url中新增版本號，比如
如果整個介面系統的根基都發生變動的話，比如微博api，從oauth1.0公升級到oauth2.0，整個api都進行了公升級。
有時候，乙個介面的變動還會影響到其他介面，但做的時候不一定能發現。因此，最好還要有一套完善的測試機制保證每次介面變更都能測試到所有相關層面。
關於介面設計，暫時想到的就這麼多了。各位看官看完覺得有遺漏或有哪些需要優化的歡迎提出一起討論。
App架構設計經驗談 介面的設計
末尾有彩蛋 使用者用密碼登入成功後，伺服器返回token給客戶端 客戶端將token儲存在本地，發起後續的相關請求時，將token發回給伺服器 伺服器檢查token的有效性，有效則返回資料，若無效，分兩種情況 token錯誤，這時需要使用者重新登入，獲取正確的token token過期，這時客戶端需...
App架構設計經驗談 介面的設計
安全機制的設計 使用者用密碼登入成功後，伺服器返回token給客戶端 客戶端將token儲存在本地，發起後續的相關請求時，將token發回給伺服器 伺服器檢查token的有效性，有效則返回資料，若無效，分兩種情況 token錯誤，這時需要使用者重新登入，獲取正確的token token過期，這時客戶...
App架構設計經驗談 服務端介面的設計
使用者用密碼登入成功後，伺服器返回token給客戶端 客戶端將token儲存在本地，發起後續的相關請求時，將token發回給伺服器 伺服器檢查token的有效性，有效則返回資料，若無效，分兩種情況 然而，此種驗證方式存在乙個安全性問題 當登入介面被劫持時，黑客就獲取到了使用者密碼和token，後續則...