App架構設計學習（一）---- 接口的設計

1、哎，最近換了家工做，結果工做很出的我意外，沒有幹熟悉的根據需求寫代碼，反而讓我一個小菜鳥去重構一下App的架構（他們公司的app，已經上線了1.0版本了），沒辦法，只有硬着頭皮去先學習學習，再總結總結。

 Hybrid APP架構設計思路 ---> https://segmentfault.com/a/1190000004263182

二,App與服務器的通訊接口如何設計得好,能夠從如下這幾個方面考慮

  一、 安全機制的設計  

        ----> 待研究

  二、 接口數據的設計      

　　接口的數據通常都採用JSON格式進行傳輸，不過，須要注意的是，JSON的值只有六種數據類型：

　　Number：整數或浮點數

　　String：字符串
　　Boolean：true 或 false
　　Array：數組包含在方括號[]中
　　Object：對象包含在大括號{}中
　　Null：空類型
　　因此，傳輸的數據類型不能超過這六種數據類型。之前，咱們曾經試過傳輸Date類型，它會轉爲相似於"2016年1月7日 09時17分42秒 GMT+08:00"這樣的字符串，這在轉換時會產生問題，不一樣的解析       庫解析方式可能不一樣，有的可能會轉亂，有的可能直接異常了。要避免出錯，必須作特殊處理，本身手動去作解析。爲了根除這種問題，最好的解決方案是用毫秒數表示日期。

　　另外，之前的項目中還出現過字符串的"true"和"false"，或者字符串的數字，甚至還出現過字符串的"null"，致使解析錯誤，尤爲是"null"，致使App奔潰，後來查了很久才查出來是該問題致使的。這都是      由於服務端對數據沒處理好，致使有些數據轉爲了字符串。因此，在客戶端，也不能徹底信任服務端傳回的數據都是對的，須要對全部異常狀況都作相應處理。

　　服務器返回的數據結構，通常爲：

　　{
　　code：0
　　message: "success"
　　data: { key1: value1, key2: value2, ... }
　　}
　　code: 狀態碼，0表示成功，非0表示各類不一樣的錯誤
　　message: 描述信息，成功時爲"success"，錯誤時則是錯誤信息
　　data: 成功時返回的數據，類型爲對象或數據
　　不一樣錯誤須要定義不一樣的狀態碼，屬於客戶端的錯誤和服務端的錯誤也要區分，好比1XX表示客戶端的錯誤，2XX表示服務端的錯誤。這裏舉幾個例子：

　　0：成功
　　100：請求錯誤
　　101：缺乏appKey
　　102：缺乏簽名
　　103：缺乏參數
　　200：服務器出錯
　　201：服務不可用
　　202：服務器正在重啓
　　錯誤信息通常有兩種用途：一是客戶端開發人員調試時看具體是什麼錯誤；二是做爲App錯誤提示直接展現給用戶看。主要仍是做爲App錯誤提示，直接展現給用戶看的。因此，大部分都是簡短的提示信      息。

　　data字段只在請求成功時纔會有數據返回的。數據類型限定爲對象或數組，當請求須要的數據爲單個對象時則傳回對象，當請求須要的數據是列表時，則爲某個對象的數組。這裏須要注意的就是，不要將      data傳入字符串或數字，即便請求須要的數據只有一個，好比token，那返回的data應該爲：

　　// 正確
　　data: { token: 123456 }

　　// 錯誤
　　data: 123456

  三、接口版本的設計

　　接口不可能一成不變，在不停迭代中，總會發生變化。接口的變化通常會有幾種：

　　數據的變化，好比增長了舊版本不支持的數據類型
　　參數的變化，好比新增了參數
　　接口的廢棄，再也不使用該接口了
　　爲了適應這些變化，必須得作接口版本的設計。實現上，通常有兩種作法：

　　每一個接口有各自的版本，通常爲接口添加個version的參數。
　　整個接口系統有統一的版本，通常在URL中添加版本號，好比http://api.domain.com/v2。
　　大部分狀況下會採用第一種方式，當某一個接口有變更時，在這個接口上疊加版本號，併兼容舊版本。App的新版本開發傳參時則將傳入新版本的version。

　　若是整個接口系統的根基都發生變更的話，好比微博API，從OAuth1.0升級到OAuth2.0，整個API都進行了升級。

　　有時候，一個接口的變更還會影響到其餘接口，但作的時候不必定能發現。所以，最好還要有一套完善的測試機制保證每次接口變動都能測試到全部相關層面。

3、只是爲了記錄學習別人的知識，好的地方是直接粘貼過來的，請各位看官見諒。