查询一下网络请求，你会发现这种，是不是真的这么简单？可以参考一下
http://www.cocoachina.com/ios/20161107/17981.html?utm_source=tuicool&utm_medium=referral

我理解的正如评论所说的，post无法。
这个每个公司是不一样，不过感觉都喜欢post，毕竟稍微安全点。

so，自带缓存可能不一定合适。最流行的流行afn和yycache组合，yycache内存和硬盘缓存会比较快。

现在剩下思路：
什么需要缓存？（这部分只说网络缓存，用户数据缓存的话，可以是归档、数据库等）
何时更新？
最最重要的是要根据现有项目情况来做出相应的修改。

什么需要缓存。
一般请求分成二种，一种是展示(不一定缓存，按需求)，一种是修改，修改结果的接口我们不需要缓存（修改都是post），我们需要缓存的是展示的网络请求。这部分当然还需要区分，区分的依据是更新机制，如果你每次请求都更新的话，缓存就是为了用户体验（防止用户网卡）。如果你是根据后台某个通知机制去更新，那就是一些不太常改变的数据缓存。我们可以封装相应的api请求接口，根据需求情况相应改变。

那么现有问题又是如何去更新？
1.每次api接口请求时更新；
2.根据某个消息通知更新。（app存在多端操作，以及上级可以修改下级状态）

github上会有几个afn和yycache封装的缓存库
我选择了PPNetworkHelper。
大致思路，可以看下方法回调，如果需要缓存的话，去内存缓存（优先内存缓存，没有硬盘缓存）查找，有就先返回缓存，没有的话，返回nil，当网络请求有返回时，根据返回，返回成功或者失败数据。如成功，缓存请求成功的数据。

项目情况（原网络框架，afn封了一成）
项目暂无一个很好的更新机制，且一个用户相应身份权限都基础数据需要大致5-8个接口（这部分缓存是希望体验好点，app内信息查询根据令另外的数据缓存），同时由于无法判断身份（后期app端不判断，接口判断能否正常调用）以前版本需要实时判断，体检较差。
展示页面，根据返回显示
列表页面，根据返回显示，同时支持返回，搜索（网络请求）

修改方案：（在ppnetworkhelper上封装一层，ydnetworkhelper，然后原网络框架套在ydneiworkhelper上）
修改思路：需要缓存的数据，每次接口请求，优先加载缓存（如有），再返回网络数据。
单纯的无列表展示页面就这样。
然后当碰到列表页面的时候，就有问题了。
列表翻页时是要模型加到数据，如果返回二次的话，数据就不对了。所以我们自己的ydnetworkhelper上最好把缓存和成功（正常），以及缓存和失败（这部分依照自己意愿，失败情况，网络慢，身份等等）的写在二个block上，而不是分开的三个block。

在相应的控制器或者presenter上去修改。
1.有缓存，无网络请求
2.无缓存，有网络请求
3.有缓存，有网络请求
4.无缓存，无网络请求（忽略）

无缓存时，执行：--->2 2执行加到数组，刷新列表
有缓存时，执行：1--->3 2执行加到数组，刷新列表 3执行删除缓存加到数据的个数，同时把网络请求数据的模型加到数组刷新。

本来考虑了线程，如果网络比较好的话，可以把1这步取消，后来发现删除是按数据个数的，如果加了线程可取消的话，还需要其他判断，同时无法定义网络好坏，因为暴露给了p或者c，代码量就比较多，同时，一般一页只设置了10到20个数据，暂放弃。

以上仅测试阶段，工作量较大，慢慢修改。