最近我们前台架构的契约发生一次漏洞，造成契约脑裂。由于开发时间比较紧张，没有太多时间在协议上下功夫，在联调过程中造成不必要的弯路。
Content-Type是什么？
在RESTful接口的每个请求和响应中都会有Content-Type属性，存放在header头中。若是POST请求时必须要指定请求头Content-Type属性，一般我们使用
application/x-www-form-urlencoded
multipart/form-data
application/json
这两种格式在什么场景下使用？
若请求表单中使用上传文件（type=file）时，Content-Type需要设置为multipart/form-data。其它场景可以直接使用application/x-www-form-urlencoded。
在互联网项目中已经普遍采用json的格式进行传输，若要请求使用json进行传输需要在请求头设置Content-Type=application/json。那么我们讨论一下这三种类型如何在前台架构中更好的使用。
1. multipart/form-data
若指定此类型，是支持上传文件，表单需要指定type=file。那么我们在springmvc框架中有以下几种方式获取参数。
一种是使用HttpServletRequest 转化成MultipartHttpServletRequest对象，然后通过multipartRequest.getFile('file')的方式获取参数
public UploadVO upload(HttpServletRequest request) {
MultipartHttpServletRequest multipartRequest = (MultipartHttpServletRequest) request;
MultipartFile uploadFile = multipartRequest.getFile('file');
}
另一种是通过springmvc框架完成封装参数。需要使用@RequestParam 对参数进行接收，spring框架会自动转成MultipartFile类型
public ResponseVO save (@RequestParam(value = 'file', required = false) MultipartFile file) {
…
}
2. application/x-www-form-urlencoded
默认表单提交采用此类型，也是标准类型。可以直接使用springmvc框架进行封装参数
public ResponseVO getInfo(String custId) {
…
}
此方法虽然是标准方式，但若参数是个复杂参数时，springmvc无法自动对参数进行很好的封装。那么我们就会采用第三种类型。
3. application/json
若请求头采用此类型，优点是可以处理复杂的参数类型，如多层对象封装可以很好的支持。缺点是原来的方式无法满足要求，需要重新开发接口对此类型进行接收。
public ResponseVO getInfo(@RequestBody User user){
…
}
Springmvc框架提供了@RequestBody 来自动封装参数，若是@RequestBody注解的参数则使用RequestResponseBodyMethodProcessor进行解析参数.
这种方式获取参数时，参数必须只有一个并且使用@RequestBody进行注解，若多个参数时必须使用对象进行封装。
所以若采用第三种类型，则不建议要支持前两种协议。所以通过这次问题，我们协定了使用application/json只有在复杂对象时才可以使用。其它场景依然使用标准方式。
这里没有说明，这次遇到的问题的调用接口方是H5端。我们对应有多端，不但有H5，还有ios和android。另两端因只支持标准方式，所以原使用复杂对象的参数，则在调用方对参数进行转成json字符串，然后接收方进行使用String进行接收，然后转化成对象。
联系客服
