背景

在前后端分离的开发组中，

前端通常对自己代码组织的比较细致，都会对AJAX，或者小程序API做封装。

而很多前端开发对后端接口要求的传参一头雾水，后端开发人员对HTTP一知半解，传参接收不到，说不清楚，互相推脱，谁谁应该改传参方式。

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

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

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

吐槽：本人来公司一年了，总是在给同事讲这个Content-Type。

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和表单其实是一样的，都是在请求体里面。

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

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

使用上面的表单2，伪JSON表单，这种情况的坏处就是JAVA后端的 Model解析比较别扭，不太好建模。
使用URL + 公共参数、Token，其余参数放在Body，以POST JSON传参，没有坏处，好处就是后端做拦截器，或者Filter的时候比较统一明了，不需要在Model里面涉及公共参数。唯一的坏处就是，前端同学可能懒得弄。

前端封装的框架，必须支持公共参数追加到URL，并且可以以JSON传参。
后端就可以依据以上的情况，灵活使用参数组织方式了，处理业务的代码专心接受参数，
拦截器直接通过URL获取公共参数和Token，来做一些版本控制，身份认证等功能。

如果前端不支持混和传，要么都在JSON内，要么在URL上面，网上一堆文章说接收不到参数，一边倒说改成表单，改成GET等诸如此类。
那这开发素质需要提升了。

问题是：微信小程序API request 是支持的application/json的！！！