HTTP Content-type 与 AFNetworking--Mark过来备用

转自isaced

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 对象，我简单画了个图以看得更清晰：

试了下百度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端，我们有两种解决方案：

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

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

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

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