Retrofit :A type-safe HTTP client for Android and Java.
retrofit : noun. a component or accessory added to something after it has been manufactured
mocky.io: Mock your HTTP responses to test your REST API
前言
本文默认ConverterFactory
为GsonConverterFactory
。
请求阶段
- Header的统一处理
- 访问绝对路径
- Map的使用避免声明冗余的类
- RequestBody为String 及 文件上传
返回阶段
- 后台Json空数据规范
- 空数据Void声明
- ResponseBody为String
- ResponseBody的多次读取
- 统一的错误处理
Header的统一处理
使用Interceptor
可为每一个request
添加统一的Header
信息
|
|
访问绝对路径
- @Url
@URL resolved against the base URL.
这种方式是动态的灵活的,不需要提前预知的。
|
|
- endpoint为绝对路径
这种方式需要在编码时提前预知,与baseUrl
的理念是相冲突的,不推荐使用这种方式。
Map的使用避免声明冗余的类
QueryMap为Query支持复杂的、不定数的字段。
对应的Body也可以通过定义参数类型为Map来避免声明冗余的类。
以下代码为了Post
/Put
的Body
特别定义了个IsReead
类,实现方式有些重!
|
|
与如下代码的功能是相同,但更简单明了的:
|
|
同样的,在请求的返回阶段,如果返回内容都是单纯的key: value,那ResponseBody也可以定义为Map。
不必每个接口都有对应的数据类。
RequestBody为String 及 文件上传
App中嵌套的H5页面传给App的内容是Json格式化的字符串,并要作为Body发起Post/Put请求,这时则希望RequestBody为String,则处理为:
|
|
如果将MediaType改为图片、视频等对应的MediaType值,则很可很方便的实现文件上传接口:
|
|
后台Json空数据规范
客户端请求数据时,后台对空数据的返回应该是要有规范的,
应该按Json格式返回 [] 空数组或 {} 空对象,不应什么都不返回.
什么都不返回会导致Json解析异常,会误导客户端判定连接为CMCC/ChinaNet等假网络,导致提示网络异常,与实际情况不符。
喂喂,后台同学,都是开发狗,能不能别互相伤害
空数据Void声明
如果只需要发个请求然后根据response code为HTTP_OK(200)即可,而不需要后台回吐额外的数据,在定义接口时可以声明ResponseBody为Void。
|
|
ResponseBody为String
当要将后台回吐的数据通过App传参给内嵌的H5页面时,这时希望ResponseBody为String,应该这么做:
|
|
ResponseBody的多次读取
当试图去读取response body的原始数据时,由于是从网络上以stream的方式读取的,所以多次读取的话会抛如下异常:
|
|
|
|
实现了多次读取的功能后,就可以进行下面的统一错误处理了。
统一的错误处理
发起一次请求后可能产生的错误有:
网络问题:
- 无网络访问失败
- 链接超时等IO异常
- 假网络链接
后台提示错误:
- 请求参数不规范
- 业务逻辑错误,如提交的内容包含敏感词
- Json解析失败
response code
不是HTTP_OK
以上错误会分散在Callback
的onResponse()
及onFailure()
中去。
不利于技术层的数据统计及业务层的错误兼容。
那么在做统一的错误处理时,目标有:
onResponse()
是纯粹的success
回调,剥离了response code
或解析失败等异常。- 能够读取后台返回的数据源进行处理后,不影响数据源的继续传播与解析。即上文提到的多次读取。
能够统一进行错误处理的方式有Interceptor
及对Callback
进行override
。
个人选择Callback override
的方式,个人观点希望每个类是尽可能可复用的,对于每一次request
,都有对应的Callback
,那么就不想再定义新的类(Interceptor
)来处理。
而且每一个request
都有新的callback
的实例对象,也好进行一些个性化的错误处理。
新的Callback
代码如下:
|
|