HTTP Content-type 与 AFNetworking

这篇文章主要记录一下之前爬过的一个坑,关于使用 AFNetworking 中请求数据和 HTTP 的 Content-type 关系。

在 iOS 端我们常用 JSON 来作为数据传输格式,对于 HTTP 网络通信框架现在也是 AFNetworking 居多,在 AFNetworking 2.0 ,有了比较大的变化,引入了 iOS 7 / Mac OS X 10.9 的 NSURLSession ,而在 AFNetworking 中对 JSON、XML 等数据对象都有良好的支持,在文档中就可以看到新增了 Serialization 对象,我简单画了个图以看得更清晰:

Serialization

试了下百度 FEX 开发的在线脑图工具 kityminder ,并且是开源项目,还真方便,点这里还可以在线查看。

可以看到 Serialization 派生出 AFURLRequestSerializationAFURLResponseSerialization ,分别作为请求数据和接受数据的序列化方式。AFURLResponseSerialization 又派生出好几种响应数据序列化方式,能正确的使用他们将给我们带来极大的方便。

像我们如果用 AFHTTPSessionManager 的话,在初始化后就会设置一个属性 responseSerializer,这就是上图所述的 AFURLResponseSerialization,告诉 AFNetworking 以怎样的方式接受数据,如果后段接口都是标准的 JSON 数据格式,那么很愉快的就选择了 AFJSONResponseSerializer ,在请求成功的 Block 中的responseObject 就会是一个 AFNetworking 帮你解好档的 JSON,也就是一个 NSDictionary对象。

但有时候你是否遇到明明接口是返回的 JSON 数据,可用 AFJSONResponseSerializer 就会报错,错误信息类似:

Request failed: unacceptable content-type: text/html

这就是因为 HTTP 响应头中的 Content-Type 字段对不上号,最简单的方法就是在浏览器的开发者工具中看到:

response header

如果接口返回的 Content-Type 和实际情况不合时,有时候是因为后端开发人员不规范,我更有遇到一套接口中大多都是 JSON 返回,还有个别方法返回纯文本,如:“YES”,这些都是接口开发人员不规范导致的问题,作为 iOS 端,我们有两种解决方案:

  1. 告诉接口开发人员规范写法,你好我好大家好!(推荐)
  2. responseSerializer 使用 AFHTTPResponseSerializer,这样就不能享受 AFNetworking 自带的 JSON 解析功能了,拿到 responseObject 就是一个  Data 对象,需要自己根据需要进行反序列化。

关于 Content-Type ,可能还是有些同学不太清楚的,这是 HTTP 的基础知识,做后端的同学应该得知道。

Content-Type,内容类型,一般是指网页中存在的 Content-Type,用于定义网络文件的类型和网页的编码,决定浏览器将以什么形式、什么编码读取这个文件,这就是经常看到一些 Asp 网页点击的结果却是下载到的一个文件或一张图片的原因。 - via 百度百科

这里还找到一个 Content-Type 对照表:http://tool.oschina.net/commons

comments powered by Disqus