HTTP Content-type 与 AFNetworking

HTTP Content-type 与 AFNetworking

转自：http://www.isaced.com/post-254.html

这篇文章主要记录一下之前爬过的一个坑，关于使用 AFNetworking 中请求数据和 HTTP 的 Content-type 关系。
在iOS端我们常用JSON来作为数据传输格式，对于HTTP网络通信框架现在也是 AFNetworking 居多，在 AFNetworking 2.0 ，有了比较大的变化，引入了 iOS 7 / Mac OS X 10.9 的

NSURLSession

，而在
AFNetworking 中对JSON、XML等数据对象都有良好的支持，在文档中就可以看到新增了

Serialization

对象，我简单画了个图以看得更清晰：



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

可以看到

Serialization

派生出

AFURLRequestSerialization

和

AFURLResponseSerialization

，分别作为请求数据和接受数据的序列化方式。

AFURLResponseSerialization

又派生出好几种响应数据序列化方式，能正确的使用他们将给我们带来极大的方便。
像我们如果用

AFHTTPSessionManager

的话，在初始化后就会设置一个属性

responseSerializer

，这就是上图所述的

AFURLResponseSerialization

，告诉AFNetworking
以怎样的方式接受数据，如果后段接口都是标准的JSON数据格式，那么很愉快的就选择了

AFJSONResponseSerializer

，在请求成功的Block中的

responseObject

就会是一个
AFNetworking 帮你解好档的JSON，也就是一个

NSDictionary

对象。
但有时候你是否遇到明明接口是返回的JSON数据，可用

AFJSONResponseSerializer

就会报错，错误信息类似：

Request failed: unacceptable content-type: text/html

这就是因为HTTP响应头中的

Content-Type

字段对不上号，最简单的方法就是在浏览器的开发者工具中看到：



如果接口返回的

Content-Type

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

告诉接口开发人员规范写法，你好我好大家好！（推荐）

responseSerializer

使用

AFHTTPResponseSerializer

，这样就不能享受
AFNetworking 自带的JSON解析功能了，拿到

responseObject

就是一个　Data
对象，需要自己根据需要进行反序列化。

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

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

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