四种常见的POST提交数据方式专题

First name:

Last name:

BASHPOST http://www.example.com HTTP/1.1

Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA------WebKitFormBoundaryrGKCBY7qhFd3TrwAContent-Disposition: form-data; name=\"text\"

title

------WebKitFormBoundaryrGKCBY7qhFd3TrwA

Content-Disposition: form-data; name=\"file\"; filename=\"chrome.png\"Content-Type: image/png

PNG ... content of chrome.png ...

------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

这个例⼦稍微复杂点。⾸先⽣成了⼀个 boundary ⽤于分割不同的字段，为了避免与正⽂内容重复，boundary 很长很复杂。然后 Content-Type ⾥指明了数据是以 multipart/form-data 来编码，本次请求的 boundary 是什么内容。消息主体⾥按照字段个数⼜分为多个结构类似的部分，每部分都是以 --boundary 开始，紧接着是内容描述信息，然后是回车，最后是字段具体内容（⽂本或⼆进制）。如果传输的是⽂件，还要包含⽂件名和⽂件类型信息。消息主体最后以 --boundary-- 标⽰结束。关于 multipart/form-data 的详细定义，请前往 查看。

这种⽅式⼀般⽤来上传⽂件，各⼤服务端语⾔对它也有着良好的⽀持。

上⾯提到的这两种 POST 数据的⽅式，都是浏览器原⽣⽀持的，⽽且现阶段标准中原⽣ 表单也（通过 元素的 enctype 属性指定，默认为 application/x-www-form-urlencoded。其实 enctype 还⽀持 text/plain，不过⽤得⾮常少）。

随着越来越多的 Web 站点，尤其是 WebApp，全部使⽤ Ajax 进⾏数据交互之后，我们完全可以定义新的数据提交⽅式，给开发带来更多便利。

application/json

application/json 这个 Content-Type 作为响应头⼤家肯定不陌⽣。实际上，现在越来越多的⼈把它作为请求头，⽤来告诉服务端消息主体是序列化后的 JSON 字符串。由于JSON 规范的流⾏，除了低版本 IE 之外的各⼤浏览器都原⽣⽀持 JSON.stringify，服务端语⾔也都有处理 JSON 的函数，使⽤ JSON 不会遇上什么⿇烦。

JSON 格式⽀持⽐键值对复杂得多的结构化数据，这⼀点也很有⽤。记得我⼏年前做⼀个项⽬时，需要提交的数据层次⾮常深，我就是把数据 JSON 序列化之后来提交的。不过当时我是把 JSON 字符串作为 val，仍然放在键值对⾥，以 x-www-form-urlencoded ⽅式提交。Google 的 中的 Ajax 功能，默认就是提交 JSON 字符串。例如下⾯这段代码：

JSvar data = {'title':'test', 'sub' : [1,2,3]};

$http.post(url, data).success(function(result) { ...});

最终发送的请求是：

BASHPOST http://www.example.com HTTP/1.1 Content-Type: application/json;charset=utf-8{\"title\":\"test\1,2,3]}

这种⽅案，可以⽅便的提交复杂的结构化数据，特别适合 RESTful 的接⼝。各⼤抓包⼯具如 Chrome ⾃带的开发者⼯具、Firebug、Fiddler，都会以树形结构展⽰ JSON 数据，⾮常友好。但也有些服务端语⾔还没有⽀持这种⽅式，例如 php 就⽆法通过 $_POST 对象从上⾯的请求中获得内容。这时候，需要⾃⼰动⼿处理下：在请求头中 Content-Type为 application/json 时，从 php://input ⾥获得原始输⼊流，再 json_decode 成对象。⼀些 php 框架已经开始这么做了。当然 AngularJS 也可以配置为使⽤ x-www-form-urlencoded ⽅式提交数据。如有需要，可以参考。

text/xml

我的博客之前（XML Remote Procedure Call）。它是⼀种使⽤ HTTP 作为传输协议，XML 作为编码⽅式的远程调⽤规范。典型的 XML-RPC 请求是这样的：

HTMLPOST http://www.example.com HTTP/1.1 Content-Type: text/xml

examples.getStateName

41

XML-RPC 协议简单、功能够⽤，各种语⾔的实现都有。它的使⽤也很⼴泛，如 WordPress 的 ，搜索引擎的 等等。JavaScript 中，也有⽀持以这种⽅式进⾏数据交互，能很好的⽀持已有的 XML-RPC 服务。不过，我个⼈觉得 XML 结构还是过于臃肿，⼀般场景⽤ JSON 会更灵活⽅便。

最近为项⽬组提供rest api 时遇到了关于接⼝参数的传递问题，主要是没有充分考虑到第三⽅调⽤者的使⽤⽅式，应该尽量的去兼容公司之前提供出去的接⼝调⽤⽅式，这样可以降低第三⽅调⽤者的学习成本，尽管之前的⽅式并不是那么的推荐，好的做法是即兼容⽼的做法也⽀持推荐的做法。

对于基于http post接⼝，Content-type我会优先选择application/json,但公司之前提供的接⼝恰恰采⽤了application/x-www-form-urlencoded，它是表单默认的提交类型，基于key/value形式提交到服务端的。

spring mvc是如何接收下⾯两种经典数据的? (⾄于form-data，它即可以传键值对也可以上传⽂件，这⾥不涉及到⽂件所以只讨论下⾯两种)：

Content-type=application/json：需要在参数上增加@RequestBody这个注解，说明参数是从http的requestbody中获取。

下图中的参数，是标准的json格式，对前端js⾮常友好。

Content-type=application/x-www-form-urlencoded，参数上不能增加@RequestBody的注解下图的可以看出参数形式与get请求时，URL后⾯的参数格式

为什么不推荐采⽤application/x-www-form-urlencoded这种类型，它有如下问题：

测试困难,就别想通过postman这类⼯具测试：提交到服务端实际上是⼀个MultiValueMap(org.springframework.util.MultiValueMap或org.springframework.util.LinkedMultiValueMap)，

如果value中的对象也是⼀个对象，那么在构建这个参数时就⾮常困难，看下它的过程

采⽤key1=value1&key2=value2这种形式将所有参数拼接起来，从⼀长串字符中想了解每个参数的含义没有个好眼⼒怕是不⾏。value要进⾏编码，编码之后的对调试者不友好。

value是复杂对象的情况更加糟糕，⼀般只能通过程序来序列化得到参数，想⼿写基本不可能。客户端调⽤复杂

需要去构建List，⼀般页⾯传递的参数都是⼀个实体对象Model，需要额外的将这个Model转换成List，如果这个对象复杂，那么构建这个Key/Value就够⼈烦的了。

这⾥给⼀个java通过apache httpclient调⽤的对⽐，看看哪⼀个简单。

application/x-www-form-urlencoded需要⼿⼯将model转换成NameValuePair。

application/json

这⾥只需要Model即可，不需要⼆次转换，结构也⾮常清楚。

key/value的语⾔表达形式没有json强，下⾯两种你更加喜欢哪⼀个呢？字符串

post man这类模似http请求的⼯具中，如果key对应的value是个对象，那么你需要通过⼯具得到它的序列化之后的字符串然后填写到字段中，想想都烦。如果你说我不需要通过这些模似⼯具测试，那就另当别论

json

数据结构更加复杂

如果需要提交的对象⾮常复杂，属性⾮常多，如果将所有的属性都构建到MultiValueMap中，那个Map的构建会⾮常复杂，试想如果对象有多级嵌套对象呢。所有为了避免这个问题，我们将需要提交的业务对象做为⼀个key来存储，value就是对象序列化之后的字符串。再加了⼀些⾮业务参数，⽐如安全⽅⾯的token等参数，有效的降低了MultiValueMap构建的复杂度。但这种⽅式相对于json的传递⽅式来讲层次更深。如下图，我们的参数多了⼀层,jsonParam。

如果解决呢？

不能不兼容现有的模式，但⼜想⽀持json，焦点就是在参数的接收上，让其能够完美的兼容上述两种参数传递，这⾥可以从HttpMessageConverter着⼿，这个就是⽤来将请求的参数映射到spring mvc⽅法中的实体参数的。我们可以编写⼀个⾃定义的类，内部借⽤FormHttpMessageConverter来接收MultiValueMap，即使⽅法参数上增加了@RequestBody的注解，也会⾛我们⾃定义的converter，就有机会去重新给参数赋值。

这个⽅法中需要解决⼀个问题，就是客户端传递时每个参数都是当成字符串来处理的，这种导致我们通过FormHtppMessageConverter转换成Map时，原本是对象的属性被识别成字符串，⽽不是object，结果就是在反序列化时会出错。好在，上⾯我们将需要提交的对象包装了⼀次，产⽣⼀个公共的object参数jsonParam，只需要处理这⼀个特殊对象。做法就是从Map取出jsonParam，然后对其内容进⾏反序列化，更新Map值，再次进⾏反序列化就正常了。

上图中的做法⽬前有如下问题

序列化的字段是约定好的，也是基于我们的post model基本上来处理的，是针对性的converter

代码最后⾯调⽤的jackon的convertValue，对需要反序列化的对象类型有要求，好像不⽀持泛型类型，⽐如这种类型的就不⾏：CommonParamInfoDto>

完整的conveter代码如下，其实主要代码就是上图贴图中的那么对特定字段的序列化处理，其它的⽅法都是默认即可。

public class ObjectHttpMessageConverter implements HttpMessageConverter