大橙子网站建设,新征程启航
为企业提供网站建设、域名注册、服务器等服务
这篇文章主要介绍“postman使用@ResquetBody和@RequestParam需要注意什么”,在日常操作中,相信很多人在postman使用@ResquetBody和@RequestParam需要注意什么问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”postman使用@ResquetBody和@RequestParam需要注意什么”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
专注于为中小企业提供网站建设、网站制作服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业镇江免费做网站提供优质的服务。我们立足成都,凝聚了一批互联网行业人才,有力地推动了近1000家企业的稳健成长,帮助中小企业通过网站建设实现规模扩充和转变。
如今前后端分离之后,大多采用json格式的数据进行交互,Java后台一般也就采用发现用@ResquetBody和@RequestParam两个注解进行接收参数。
常规做法是:
@ResquetBody用来接收一个复杂的包装类型,比如:
@RequestBody AuthApplyDto authDto
@Data public class AuthApplyDto { private int id; private String status=""; private String userId=""; ... }
@ResquetParam用于接收基本类型或者基本类型及String对象。当然,如果请求参数不复杂,使用多个@ResquetParam也可达到@ResquetBody同样的效果(如果参数不多的时候)。
但是,很有可能你会遇到下面的情况:
"Required String parameter 'userid' is not present"
此时,你需要重新审视这两个注解的使用场景了。
后台参数接收如下:
@RequestParam(name="userid") String userId, @RequestParam(name="resourceid") String resourceId)
情况一:get方式请求,请求参数如下:
{ "userid":1, "resourceid":"18" }
测试结果:后台可以接收。
情况二:post方式请求,json序列化传递,请求参数同上。后台报错如下:
呵呵,这个几个意思,明明传递了userid,却提示我没有传,不科学啊!!!仔细一想,问题肯定出在后台对参数的解析上。
情况三:同时注意到,如果采用form-data的方式则可以成功请求。
情况四:如果采用x-www-form-urlencoded的方式也可以成功请求
那为什么同样是post请求,json格式的数据却无法解析。这是因为第三种和第四种都是以表单数据提交,content-Type并不是application/json。更多详情参见:四种常见的 POST 提交数据方式
也就是说Content-Type = application/x-www-form-urlencoded(或者 multipart/form-data) 的编码方式,二者是表单请求,可以用@RequestParam一个一个获取参数。而 Content-Type = application/json 的时候参数获取不到。并且会报错:
- Required String parameter ‘xx’ is not present
那对于application/json的编码,应该怎么接收呢,答案则是@RequestBody。此注解能够做json格式的解码和编码。
后台参数接收:
@RequestBody AuthApplyDto authDto
情况一:json格式传递,post请求,测试结果成功。
情况二:如果使用@RequestBody接收参数,使用表单格式post请求,又会发生什么呢?答案是不支持。
情况三:如果,请求方式为get,后台参数接收@RequestBody ,如下格式,会发生什么呢??答案是肯定的。
测试结果如下:
疑问,这两个注解底层如何做适配解析的?
如果请求数据为数组,比如:
{ "ids":[1,2] }
后台需要做如下包装,便可接收。
@RequestBody DeleteIds ids, @Data public class DeleteIds { private Setids; }
到此,关于“postman使用@ResquetBody和@RequestParam需要注意什么”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注创新互联网站,小编会继续努力为大家带来更多实用的文章!