前言
今天和公司后台对接接口时,发生了一件很有意思的事情,他写了一个登录接口,我使用axios进行post请求,我传了用户名和密码过去,接口没有调用成功,后台看了日志后,说我没传参,然后发了一张他自己测试接口的成功截图。于是我就进入了找bug环节🤒
接下来就跟大家分享下,我踩的这个坑,欢迎各位感兴趣的开发者阅读本文。
问题背景
上图所示,就是后台给我的接口自测成功截图
我调用时,结果如下图所示
踩坑记录
接口可能为get
观察后端给的截图后,参数都在URL里,应该是get请求,于是便试了下,还真成功了
登录请求使用get方法,安全性太低了,于是跟后台说了下,后台给我的回复是,他没限制get和post请求。
此时的我是这样的
接口可能是伪post
后端说post请求可以成功,我猜测他的取值方式应该是从Query里取的,于是我改了post的写法,将参数拼接在了url里。
果然不出我所料,调用成功了。
此时的我是这样的
说服后端
post请求从url里读参,这显然是不合理的,根据上述问题,我扩展出了3个知识点,打算从这3个知识点出发说服后端,让他改接口的取参方式。
- 请求头: Query String Parameters
当发起GRT请求时,参数会以url string的形式进行传递,即问号后的字符串就是请求参数用&进行分割,如下图所示
- 请求头: Form Data
当发起post请求时,如果未指定content-type或者传递的参数为字符串,其值默认为application/x-www-form-urlencoded,此时参数就会以Form Data的形式传递,但是不会显式的出现在请求url里
使用axios发起post请求时,将params转为JSON字符串,参数就会以Form Data的形式进行传递,如下图所示
- 请求头: Request Payload
当发起post请求时,如果content-type为application/json,参数就会以Request Payload的形式进行传递。
使用axios发起post请求时,不对params做任何处理,直接传递json对象,参数就会以Request Payload的形式进行传递,这也是我想要的说服后端的用的方式。
用以上3个知识点,与后端进行沟通,最终他改了接口,使用了Request Payload方式传递参数
写在最后
- 文中如有错误,欢迎在评论区指正,如果这篇文章帮到了你,欢迎点赞和关注😊
- 本文首发于掘金,未经许可禁止转载💌
评论区