读了Casa Taloyum老师的关于iOS应用架构谈 网络层设计方案这一篇文章后收获颇多，这里自己做一个思想上的整理。
主要需要考虑的几个方面
1. 网络层和业务层的如何进行数据的交互
2. 如何提升网络请求的安全性
3. 如何优化网络请求
一、 网络层和业务层的如何进行数据的交互
1.1 选择集约型api请求，还是离散型api请求？
1.1.1 两者的区别
集约型api，就是将所有的api请求都归于一个apiManager去调配；而离散型则是根据不同的业务模块，将对应的api请求各自创建apiManager进行管理。实际上离散型api就相对于对集约型api的分类，他的上一层就是一个总的apiManager作为父类。
补充一下其实我自己的理解，集约型一般是通过类方法的方式请求api，而离散型是通过实例方法完成。后者更容易针对一个task任务的起飞降落进行管控。（ps：我觉得这才是重点）
1.12 选择哪一种？
离散型api。
1. 离散型api可以更方便地管理task任务的请求起飞和请求着陆。
2. AOP的处理方便。ios中主要体现在Method Swizzing
3. 离散型api可以根据需求增加api调用的灵活性。比如不需要进行page的管理，直接调用nextPage。
1.2 传递的数据是否需要Model化处理
不需要，直接传递json转化后的数据即可（字典或者数组）。
CT老师的想法是view即便拿到了数据也不转化成model，直接用一个转化器Reformer去对数组/字典筛选展示的数据。具体要不要这样操作，我觉得可以看看到底性能上有多少提升。
但如果没什么区别，我觉得就没必要了。比较久可读性和开发效率来讲model会更高。
原文中对数组的描述，说了5个点，我觉得可以总结为一下3点：
1. 减少不可复用的item对象（这个可以接受）
2. 数据的使用需要二次转化。（不确定性能会差多少）
3. 同意api数据被不同view展示时，难以控制数据转化的代码，他们可能会在任何地方。（这个难以理解）
1.3 通过什么方式来传递数据
网络层常用的3种数据传值方法：Notification、Delegate、Bolck。
先说结果：如果是跨层访问，如网络状态的切换，建议采用Notification（一般也只有这个会这样操作）。其他的只能上一层或下一层交互的，使用Delegate完成，不建议使用Block
下面说说block和delegate的问题
1. 使用方便性
block方便，但delegate也不差。
2. 可读性
block只能向上看，而不能向下看（查看哪些地方调用了该block）。
3. 对生命周期的影响
block会对捕捉的对象引用计数器+1，这样会造成内存泄露（这个可以用weak解决）。但造成的问题是，blcok会延长对象的生命周期。
比如说在一个控制器中请求一个api，该api的block中访问了self，在请求没有着陆之前，该控制器的内存就无法被释放。（当然你可以说主动调用task cancle来解决，那我没话说）
二、提升网络请求的安全性
主要考虑2点：
- 服务器如何辨别请求该api的客户端是被认可的客户端（防止对手爬api）
一般可以通过签名的方式实现：
服务器提供一个密钥，调用api时通过api名和参数和密钥拼接成一个参数一起发给服务器，服务器获取到了之后进过校对，判定是否来自认可的客户端。
- 客户端请求api时，如果保证传输数据的安全（运营商很喜欢往http请求中塞广告）
HTTPS
这货比http慢很多。
http耗时 = TCP3次握手
https耗时 = TCP3次握手 + SSL握手
三、网络优化
api发起请求是通过3个步骤
1. 发起请求
2. DNS域名解析获取ip
3. 根据http3次握手（https4次），连接建立
1.1 针对发起请求的优化
如果一个api对应的数据实效性够长，可以把api名、参数拼接成一个字符串然后取MD5为key，存储对应的数据。以后请求api可以先从本地获取。api的请求可以先检索本地数据。
PS：这里需要有一个本地数据的清理策略，可以根据数据的存储量或者存储时间来清理。
1.2 对重复请求的撤销
如果在上一个请求还没有结束的着陆的情况下，又发起了一个相同的请求，可以撤销后面的请求。
2.1 域名解析api耗时的问题
直接采用ip访问api
3.1 针对ip的优化
通过URLProtocol的优化，将Host转化为可获取到的速度最快的ip
