在現在的app，網絡請求是一個很重要的部分，app中很多部分都有或多或少的網絡請求，所以在一個項目重構時，我會選擇網絡請求框架作為我重構的起點。在這篇文章中我所提出的架構，并不是所謂的 最好 的網絡請求架構，因為我只基于我這個app原有架構進行改善，更多的情況下我是以app為出發點，讓這個網絡架構能夠在原app的環境下給我一個完美的結果，當然如果有更好的改進意見，我會很樂于嘗試。

　　關于網絡請求框架

　　一個好的網絡請求框架對于一個團隊來說是十分重要的。如果一個網絡請求框架沒有封裝好，或者是在設計上存在問題，那么在開發上會造成許多問題，就拿這段代碼作為例子：

　　［leaveAPI startWithCompletionBlockWith：^（BaseRequest *baseRequest， id responseObject） {

　　//check the response object

　　BOOL isSuccess = ［leaveAPI validResponseObject:responseObject］;

　　if （isSuccess） {

　　//do something.。。

　　}

　　} failure：^（BaseRequest *baseRequest） {

　　//do something.。。

　　}］;

　　上面這段代碼存在著不少的問題，比如把請求數據的判斷放到了每一個請求中、在leaveAPI的塊方法中再次調用leaveAPI、塊參數中的baseRequest并沒有實質作用等等……針對這些問題我會一一進行修正。

　　不要讓其他人做請求數據有效與否的判斷

　　在上面的代碼中，對resposeObject是否有效的判斷被設計成了BaseRequest類中的一個方法，程序員需要在調用網絡請求后，再調用該方法對responseObject進行判斷，這樣的設計存在很大的弊端。

　　在實際應用中，很多時候程序員在調用網絡請求后往往會忘記調用該方法對返回結果進行判斷，甚至忘記了存在這個方法，自行對responseObject進行判斷。首先這造成了大規模的代碼重復，另一方面，不同程序員自己編寫的判斷方法散落在各個請求中，假如app在日后更新過程中改變了這個判斷標準，會給修改帶來很大困難。