iOS 基于AF网络请求封装的简易思路

最近重新看了一下田神基于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中处理的！