背景
在前后端分离的开发组中，前端通常对自己代码组织的比较细致，都会对AJAX，或者小程序API做封装。而很多前端开发对后端接口要求的传参 一头雾水，后端开发人员对HTTP一知半解，传参接收不到，说不清楚，互相推脱，谁谁应该改传参方式。
HTTP协议中：Content-Type，估计是非常非常多的人弄不清楚。
本质上Content-Type 要么就是 text/html要么就是 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就是参数。整个内容就是为 以& 分隔的参数列表。
例子：这里用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，来做一些版本控制，身份认证等功能。
