来，我们一起来想想，先不管你使用的是什么网络请求框架，今天我们就一起来讨论一下关于请求这边业务的事儿。
我能想到的是，在做业务接口的时候，需要有如下的几个点：
1）大家应该使用的比较多的都是json吧，轻量级，解析也比较方便。
2）最外层的数据外必须要有一个状态码。
3）每种状态码，包括错误的都对应着有一个提示，每种错误码都对应着一个错误字符提示，方便后面的分析
4）可在一处配置公共的参数。
5）区分授权业务，与非授权接口。
6）可以Hook返回的数据。
7）合理的处理脏数据。
9）可上报错误接口。
一）Json小巧，方便，想当初，google的gson没有出来的时候，使用JsonObject，与JsonArray的时候，是有多么的不方便。现在用的比较方便的，可能一个是Google自家产的Gson,还有阿里那边传说中解析速度比Gson快的 Fastjson,用这个FastJson的时候，我记得是有一个包是为Android做的，比较小去除了一些不必要的东西。 ABase里面使用的转化包，如下所示：
二）暂时定义的数据结构是这样的ABase里面有一个BaseBean
三）关于每种错误码的提示，扩展可在此处添加
四）添加一些公共的请求参数
我们经常面临着，在每个请求发起时，会面临着一些公共参数，我们不期望在每个发起接口的地儿都重写，那么你后续有更多参数需要扩展，就在这个地儿写就行了。
六）Hook一些接口数据
可能有不少的同学碰到过这样的情况，后台写接口的同学忙不过来。虽然说业务接口已经定下来了，但是经常会说接口没有出来没有办法测试。 我觉得可以这样，接口已经定义出来后，可以后台的同学，或者是自己造一些数据Hook住一些待开发的接口，当调用这些接口时，读取的是按照接口数据从本地进行读取相对应的结构的数据，从来暂时不中断研发这块的开发。而在Abase中，我觉得最合适的地儿，应该是这块：
七 ) 九 ) 关于脏数据这块的问题，脏数据有可能会导致应用的Crash，任何的网络数据， 我们都不能太相信，所以这块我们需要做一些适当的异常捕捉，同时将访问的参数，接口名字，上传到服务器以方便后台的排错。
