以APP为起点构建网络请求架构

　　在现在的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在日后更新过程中改变了这个判断标准，会给修改带来很大困难。