一、网络层跟业务对接部分的设计
1) 使用哪种交互模式来跟业务层做对接？
以什么方式将数据交付给业务层？
Delegate为主，Notification为辅
原因：
尽可能减少跨层数据交流的可能，限制耦合
统一回调方法，便于调试和维护
在跟业务层对接的部分只采用一种对接手段限制灵活性，以此来交换应用的可维护性
解答：
尽可能通过Delegate的回调方式交付数据，这样可以避免不必要的跨层访问。当出现跨层访问的需求时（比如信号类型切换），通过Notification的方式交付数据。正常情况下应该是避免使用Block的。交付什么样的数据给业务层？
reformer机制能够带来以下好处：
好处1：绕开了API数据原型的转换，避免了相关成本。
好处2：在处理单View对多API，以及在单API对多View的情况时，reformer提供了非常优雅的手段来响应这种需求，隔离了转化逻辑和主体业务逻辑，避免了维护灾难。
好处3：转化逻辑集中，且将转化次数转为只有一次。使用数据原型的转化逻辑至少有两次，第一次是把JSON映射成对应的原型，第二次是把原型转变成能被View处理的数据。reformer一步到位。另外，转化逻辑在reformer里面，将来如果API数据有变，就只要去找到对应reformer然后改掉就好了。
好处4：Controller因此可以省去非常多的代码，降低了代码复杂度，同时提高了灵活性，任何时候切换reformer而不必切换业务逻辑就可以应对不同View对数据的需要。
好处5：业务数据和业务有了适当的隔离。这么做的话，将来如果业务逻辑有修改，换一个reformer就好了。如果其他业务也有相同的数据转化逻辑，其他业务直接拿这个reformer就可以用了，不用重写。另外，如果controller有修改（比如UI交互方式改变），可以放心换controller，完全不用担心业务数据的处理。
解答：
对于业务层而言，由Controller根据View和APIManager之间的关系，选择合适的reformer将View可以直接使用的数据（甚至reformer可以用来直接生成view）转化好之后交付给View。对于网络层而言，只需要保持住原始数据即可，不需要主动转化成数据原型。然后数据采用NSDictionary加Const字符串key来表征，避免了使用对象来表征带来的迁移困难，同时不失去可读性。
2) 是否有必要将API返回的数据封装成对象然后再交付给业务层？
没必要
3) 使用集约化调用方式还是离散型调用方式去调用API？
解答：
对外提供一个BaseAPIManager来给业务方做派生，在BaseManager里面采用集约化的手段组装请求，放飞请求，然而业务方调用API的时候，则是以离散的API调用方式来调用。如果你的App只提供了集约化的方式，而没有离散方式的通道，那么我建议你再封装一层，便于业务方使用离散的API调用方式来放飞请求。
小结:
- 使用delegate来做数据对接，仅在必要时采用Notification来做跨层访问
- 交付NSDictionary给业务层，使用Const字符串作为Key来保持可读性
- 提供reformer机制来处理网络层反馈的数据，这个机制很重要，好处极多
- 网络层上部分使用离散型设计，下部分使用集约型设计
- 设计合理的继承机制，让派生出来的APIManager受到限制，避免混乱
二、网络层的安全机制实现
1） 确保API的调用者是来自你自己的APP，防止竞争对手爬你的API
解决方案：设计签名
2）如果你对外提供了需要注册才能使用的API平台，那么你需要有这个机制来识别是否是注册用户调用了你的API
解决方案：设计签名
三、网络层的优化方案
1） 针对链接建立环节的优化
1.1 针对发起请求的优化手段
1.1.1 使用缓存手段减少请求的发起次数
1.1.2 使用策略来减少请求的发起次数
能不发请求的就尽量不发请求，必须要发请求时，能合并请求的就尽量合并请求
1.2 & 1.3 针对DNS域名解析做的优化，以及建立链接的优化
索性直接走IP请求，那不就绕过DNS服务的耗时了嘛
2）针对链接传输数据量的优化
各种压缩。
3）针对链接复用的优化
一个是twitter的CocoaSPDY，另一个是Voxer/iSPDY