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