[这是第二篇]
导语：去年中旬，为了精简网络层的工作，为业务定制了一个iOS的网络组件。这套组件顽强地在线上跑了大半年，没犯什么错（谢天谢地，否者就真的是ZUO DIE -> GO DIE）。
一、背景
a、原先的网络层组件从别的项目借鉴来的。网络组件中耦合些和我们无关的业务，使用起来代码写好长，简单定义一个请求大概需要100行左右，处理起来也是比较辛苦
b、大家做网络数据落地处理的方式，没有统一的方式（通知，代理等,就是不使用block）
c、AFNetworking3.0当时出来好长一段时间了，很多app网络层面临了网络组件的替换可能
d、主要还是用得太辛苦，想借着AFNetworking3.0的东风，来好好升级一下网络组件
二、业务目标
在一个app开发中，设计iOS的网络组件，需要考虑业务中实际遇到的需求。
1） post请求还是get请求
2） 普通数据请求 && 分页数据请求，前者就是数据的一次性买卖，后者是连续不断请求分页数据
3） 连续的重复请求处理 （下拉刷新等场景下）
4） 请求签名（请求数据的MD5校验）
5） Cookie的处理（主要包含登录用户的标识信息）
6） 统一的数据回调处理 （block处理）
7） 请求数据的缓存策略
三、业务使用
3.1、一般网络数据返回格式协议
{
"code": 0,
"msg": "ok",
"data": ...
}
- code描述的的是服务器返回请求的状态码，code为0时，表示请求成功，msg是状态码描述。请求成功对应ok。code为非0时候，msg描述的就是错误信息。
- data对应的内容封装的是返回的请求数据，数据可以是数组（分页请求中），数据可以是字典结构（一般请求，如详情页请求）
- 返回的网络数据可以解析成model，本质是JSON转Model，这部分工作可以交给第三方库JSONModel或YYModel，然后把数据model交给业务层去使用。
3.2、普通请求(非分页)的处理
1) 初始化请求
+ (QCBaseRequest *)normalRequestWithUrl:(NSString *)urlString
parameters:(nullable NSDictionary *)parameters
requestMethodType:(QCRequestMethodType)requestMethodType
2) 发出请求
- (void)startWithCompleteBlock:(QCRequestCompleteBlock)completeBlock;;
3) 使用
self.request = [QCBaseRequest normalRequestWithUrl:urlString parameters:nil requestMethodType:QCRequestMethodTypeGET];
[self.request startWithCompleteBlock:^(BOOL isSuccess, id _Nullable responseObj, NSString * _Nonnull errorDesc) {
NSLog(@"isSuccess = %d && errorDesc = %@",isSuccess,errorDesc);
//TODO 数据解析....
}];
3.3、分页请求的处理
- 在app中，通常列表页都支持分页请求。请求中添加page和pagesize的参数值(pagesize一般是固定的)，然后服务器根据相关信息返回对应页的数据。
1) 初始化请求
+ (QCBaseRequest *)pagingRequestWithMethodType:(QCRequestMethodType)requestMethodType
parameters:(nullable NSDictionary *)parameters;
2）使用
- (void)startPagingRequestUrl:(NSString *)urlString
completeBlock:(QCPageRequestCompleteBlock)completeBlock
3) 使用
[self.pagingRequest startPagingRequestUrl:urlString completeBlock:^(BOOL isSuccess, BOOL hasMoreData, BOOL isReset, id _Nullable dataArray, NSString * _Nonnull errorDesc) {
NSLog(@"isSuccess = %d && hasMoreData = %d && isReset = %d",isSuccess,hasMoreData,isReset);
NSLog(@"&& errorDesc = %@",errorDesc);
}];
3.4、取消请求
- 取消请求的操作还是很有必要的。主要是处于以下两个原因：
- 一个是考虑安全。如在Controller了中发出请求，请求没有返回这段时间内，用户点击去了另一个Controller，或者退出了当前的Controller，请求还未回来，一旦系统回收了这个Controller，数据落地Controller无法处理，这样就埋下了隐患。
- 另一个是为了及时更新请求。如用户下拉操作时候，同样的请求连续发出，通过取消前一个请求，保证最新发出的请求有效。当然我们也可以不取消请求，检测前一个相同请求没有落地，后续相同的请求无效的情况。（我的网络组件默认是这么做的）
四、总结
- 早期，我们采用的是离散式的网络请求API去处理请求(一个请求对应一个API)，这给了我们极大的自由，如分页请求处理等。但是随着业务增加，请求的类文件越来越多，冗余的代码也越来越多。
- 虽然我们需要自由，但是在我这一年的开发中发现，业务中似乎不太需要这种自由，规范极大地约束了自由，不需要开发者太多变化。这些规范目前看来，没有不好地方（技术不是为了炫技，应该是更好服务于业务吧，"死板"些似乎也没有错）。
- 网络层业务组件一直提供离散式的网络请求API，现在的集约式请求API正是建立在原来离散式的网络请求API的基础上的。（绕了一大圈又回来了）
源码直通车 : QSUseNetworkDemo
