最近重新看了一下田神基於AF封裝的網路請求功能，略有所心得，想寫一些自己粗淺的心得，沒有那麼多專業術語，方便自己後面檢視封裝的思路！

網路請求，簡單的理解，就是一句話：構建client，然後發出請求，接受返回資料！

然而在我們實際的工作業務中，需求是千變萬化的，一個app中的網路請求存在很多可變的元素才能滿足需求，例如：

1.包含正常介面呼叫和web service介面呼叫；

2.不同功能模組資料傳遞資料編碼方式非utf-8，包含多種編碼（對接多個老的系統的時候，可能會有）;

3.返回資料型別是不同的（json，直接就是data資料流（非Json格式），或者是XML格式的資料）;

等等.....以上這些是比較複雜的情況，也是可變元素的簡單舉例，正常的來講公司專案不會出現，編碼不一致，返回資料不一致，加密方式不一致等的問題，所以常見大部分的封裝方法都是集約式的呼叫，使用上手比較容易！

上述的問題是自身在實際工作中遇到的一些問題，因此看到田神寫的封裝方法以後，感覺離散型的呼叫方式，以及結構分層給我很大的啟發，關於集約式和離散式方法的呼叫區別優缺點，感興趣的同學可以網上查一下，這裡不做過多的說明，簡單的意思從字面就可以理解。

1.構建請求生成類，把request生成單獨分割出來，這樣構建簡單清晰明瞭。

2.構建這套API的響應類response類，把原本就只是反饋伺服器返回資訊方法，結合資料的解析，把反饋結果提升層次，遮蔽掉對開發無意義的一些狀態欄位，這樣就使返回結果可讀性更高，使用者無需關心內部的轉化！

3.構建請求管理類，呼叫生成的request以及接受返回的response，到這一步，整個請求的構建就已經完成了；

4.結合實際業務層和整個請求發起到結束來考慮構建本類baseAPi和需要設定的代理：

構建baseAPI的childDelegate方法，可能每次都需要變的引數，可能根據模組而改變的引數或者在本類中定義方法，卻沒有任何實現的方法都放在在childDelegate中，儘可能的避免因為reload父類方法而產生的很難察覺的bug，主要是為了完成request的配置資訊以及需要的快取話，設定快取的相關配置資訊；

構建baseAPI的paramSoucreDelegate方法，把引數獲取單拎出來！

構建baseAPI的callbackDelegate方法，這個就不多做說明了！

構建baseAPI的validatorDelegate方法，這個就是做請求引數的校驗以及返回資料的校驗，這個只是做初步校驗，如果校驗不通過，後續方法就不會執行了！

構建baseAPI的interceptorDelegate方法，這個是分別攔截成功和失敗前後，以及API調起前後的攔截；可以方便做一些UI或者邏輯上的處理！

構建baseAPI的reformerDelegate方法，這個是資料處理的代理方法，生產業務所需的資料，以及不同子API產生相同業務時的業務整合！

當然，如果需要快取的話，就需要在第4步的前面加上快取管理類的構建，上述簡單分析網路請求封裝的層級關係，內部實現當然還是有很多的邏輯需要在baseAPI中處理的！