13518219792
这篇文章主要介绍“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 Set ids;
} 到此，关于“postman使用@ResquetBody和@RequestParam需要注意什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！
