Content-Type 请求

背景
在前后端分离的开发组中，前端通常对自己代码组织的比较细致，都会对AJAX，或者小程序API做封装。而很多前端开发对后端接口要求的传参 一头雾水，后端开发人员对HTTP一知半解，传参接收不到，说不清楚，互相推脱，谁谁应该改传参方式。

HTTP协议中：Content-Type，估计是非常非常多的人弄不清楚。

本质上Content-Type 要么就是 text/html要么就是 json要么就是 表单。

本质上 非常简单，但总是有人搞不清楚，总是在这个上面浪费时间。

JSON
当Content-Type 为 application/json 的时候，HTTP POST请求数据必须是JSON的。
任何框架都必须遵守这个协议，如果不支持，则说明框架不完善，开发者可能知识比较片面。

例子：

HTTP POST

header:

Content-Type: "application/json"

body:

{

"key1": value1,

"key2": value2

}

其中整个JSON就是 参数本身，他没有KEY，没有名称。key1 ，key2严格说只是属性。

表单
当Content-Type 为 x-www-form-urlencoded 的时候，POST 的请求数据必须是表单的。
甚至很多开发者印象中，参数就是个名字为key 值为value这种印象，这是非常肤浅的认识。

例子：

HTTP POST

 
header:

Content-Type: "x-www-form-urlencoded"

 
body:

key1=value1&key2=value2

何为表单参数，就是以x-www-form-urlencoded为编码的数据参数，其中key1 和 key2就是参数。整个内容就是为 以& 分隔的参数列表。

表单2
例子：这里用Chrome的F12中Network类似的表示HTTP POST请求

HTTP POST

header:

Content-Type: “x-www-form-urlencoded”

body:

key1=value1

key2={“key3”:value3, “key4”: value4}

那这个其实也是表单！！！！！他的形式是表单里面嵌套了一个JSON字符串，作为其中的一个参数。

弄清楚这个了，其实根本不需要为了传参而争论半天。

什么情况应该用什么传参？
如果参数比较单一，只做GET查询的时候，建议直接GET。URL上面就是表单参数，和POST的表单一模一样。

如果参数还是比较单一，但是参数值太多了，很长很长的字符串，用POST是毋庸置疑的。
这个时候，POST JSON和表单其实是一样的，都是在请求体里面。

如果参数是结构化的，用POST JSON，毋容置疑。

如果参数是结构化的，还需要AUTH，；例如带个TOKEN，那么：

使用上面的表单2，伪JSON表单，这种情况的坏处就是JAVA后端的 Model解析比较别扭，不太好建模。
使用URL + 公共参数、Token，其余参数放在Body，以POST JSON传参，没有坏处，好处就是后端做拦截器，或者Filter的时候比较统一明了，不需要在Model里面涉及 公共参数。唯一的坏处就是，前端同学可能懒得弄。
小程序前端 与后端配合开发的经验
前端封装的框架，必须支持 公共参数追加到URL，并且可以以JSON传参。
后端就可以依据以上的情况，灵活使用参数组织方式了，处理业务的代码专心接受参数，
拦截器直接通过URL获取公共参数和Token，来做一些版本控制，身份认证等功能。