contenttype 前台架构契约之Content

大家好,今天小编来为大家解答以下的问题，关于contenttype，前台架构契约之Content这个很多人还不知道，现在让我们一起来看看吧！

最近我们前台架构的契约发生一次漏洞，造成契约脑裂。由于开发时间比较紧张，没有太多时间在协议上下功夫，在联调过程中造成不必要的弯路。

在RESTful接口的每个请求和响应中都会有Content-Type属性，存放在header头中。若是POST请求时必须要指定请求头Content-Type属性，一般我们使用

若请求表单中使用上传文件（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")的方式获取参数

publicUploadVOupload(HttpServletRequestrequest){

MultipartHttpServletRequestmultipartRequest=(MultipartHttpServletRequest)request;

MultipartFileuploadFile=multipartRequest.getFile("file");

另一种是通过springmvc框架完成封装参数。需要使用@RequestParam对参数进行接收，spring框架会自动转成MultipartFile类型

publicResponseVOsave(@RequestParam(value="file",required=false)MultipartFilefile){

2.application/x-www-form-urlencoded

默认表单提交采用此类型，也是标准类型。可以直接使用springmvc框架进行封装参数

publicResponseVOgetInfo(StringcustId){

此方法虽然是标准方式，但若参数是个复杂参数时，springmvc无法自动对参数进行很好的封装。那么我们就会采用第三种类型。

3.application/json

若请求头采用此类型，优点是可以处理复杂的参数类型，如多层对象封装可以很好的支持。缺点是原来的方式无法满足要求，需要重新开发接口对此类型进行接收。

publicResponseVOgetInfo(@RequestBodyUseruser){

Springmvc框架提供了@RequestBody来自动封装参数，若是@RequestBody注解的参数则使用RequestResponseBodyMethodProcessor进行解析参数.

这种方式获取参数时，参数必须只有一个并且使用@RequestBody进行注解，若多个参数时必须使用对象进行封装。

所以若采用第三种类型，则不建议要支持前两种协议。所以通过这次问题，我们协定了使用application/json只有在复杂对象时才可以使用。其它场景依然使用标准方式。

这里没有说明，这次遇到的问题的调用接口方是H5端。我们对应有多端，不但有H5，还有ios和android。另两端因只支持标准方式，所以原使用复杂对象的参数，则在调用方对参数进行转成json字符串，然后接收方进行使用String进行接收，然后转化成对象。

文章分享结束，contenttype和前台架构契约之Content的答案你都知道了吗？欢迎再次光临本站哦！