背景
在前后端分离的开发组中,
前端通常对自己代码组织的比较细致,都会对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就是参数。整个内容就是为 以& 分隔的参数列表。
表单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和表单其实是一样的,都是在请求体里面。
如果参数是结构化的,用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的!!!
网友评论