《iOS网络高级编程》读书总结

前几天读了《iOS网络高级编程》，现将感想收货记录总结一下。

起因

因为自家的App在网络层有错误产生的时候一律都弹出来，这样做一来是对用户不友好，二是什么错都用alert弹出来，有时候多个请求都是404直接弹出来也很傻。本人就思考怎么处理错误比较好，一边想一边google，最终得出的方案就是根据http返回码加上自家后台返回的规定好的error结合来细分。下面细说：

解决方案

首先根据http response status code来划分成两类，如果http response status code不是200可以根据返回的实际情况，可以在控制器上提示用户当前的网络情况。如果是http response status code是200就但是后台报错，就直接把后台报错弹出来。因为现在用的这套后台时间比较长了，规则定义的不是很清晰，有些错误弹出来不是，不弹出来也不是。重新来做的话，可以将规则定义的更详细一些。

上面的内容看起来跟标题似乎关系不是很大，下面开始谈谈《iOS网络高级编程》的读后感想与收货。
之前在解决上面这个问题的时候，Google到一遍文章里面谈服务版本化的时候提到了这本书，所以就去图书馆借来读一读。其实这本书15年的时候就从图书馆借来读过，只不过自己当时实在太菜，匆匆读了一小部分就还掉了。这次读收货还是挺大的。

针对服务端，本书提出了三种模式，分别是远程门面、API版本华以及服务定位器。

远程门面

一个App可能与多个系统有交互，这些系统的数据交换方式都不太一样，比如JSON，XML或者其它数据格式（我也不知道其它是什么，工作中只用过JOSN）。如果App已经上线，后期增加了新的系统交互，那iOS App是不是又要重新发布新版呢？有了远程门面模式，就很简单了，我们的App只跟“远程门面”进行直接交互，统一数据格式，具体与其它系统的交互，统一由“远程门面”负责处理。书上提到模式应该是应用于客户端，但是我感觉这项工作由后端代劳了（好像自打工作，我们移动端的同事一般只跟“后台”同事直接打交道），看完这本书，想来自家的后台应该是已经运用了这种模式。毕竟业务上App也是与其它系统有过交互的，但是数据交互的方式与规则都是最初定下来的。
下面摘录一下当时的笔记

门面可以将请求转换为后端系统所需的格式，比如可以将JSON请求转化为SOAP请求。还可以将无法公开到Internet的其它系统强制施加安全约束，在转发请求前追踪和验证API key，限制发送给某些后端系统的请求数量。设计良好的API可以适应变化的后端数据源同时为依赖它的应用提供不变的门面。

这个模式介绍完了感觉像是反向代理，客户端直接找远程门面，远程门面找谁了客户端不关心也不知道

服务版本化

之前自家的App都是强制升级，所以根本不知道服务版本华的概念，知道这个概念也是顺藤摸瓜找到了这本书才知道的。关于这个概念这周跟后台的同事交流了一下，他也没有做过。但是有些API其实也考虑了版本，只不过整个系统设计的时候其实并没有这个概念。另外，本人感觉服务版本华对客户端的影响并不大，主要的逻辑处理都在服务端。

服务定位器

这个模式读完书上的内容没有看懂到底有什么作用，只知道客户端在发送网络前要加载解析一个服务相关的文件。
等将来明白了再来这里补充。 摘抄一段笔记：

服务定位器可以使应用能够动态检测到新的服务短点并使用它们，从而无须重新编译并重新向App Store提交应用。

其他

平时项目中常用的AFNetWorking是基于NSURL这一层封装的，NSURL相关的类是基于CFNetWork封装的，CFNetWork是基于BSD Socket封装的。再往下就是硬件层了。
除了NSURL以外，GameKit和Bonjour也可以用来在不同的端之间进行交互，并且GameKit和Bonjour都提供了离线交换数据的功能。对这些东西不是很熟悉，以后用到了再详细看）

TODO：

下次做项目尝试对网络层重新封装，把每个请求封装成一个类。