【SpringMVC】深入剖析使用 Postman 在哀求中通报对象类型、数组类型、参数
https://i-blog.csdnimg.cn/direct/a9d3553301c848ff9cad6aa4116248ea.gif#pic_centerhttps://i-blog.csdnimg.cn/direct/d280b181bfac4d0cb3d32e48da377bcb.png
https://i-blog.csdnimg.cn/direct/cd5abfb0ba1c49128b69f4ebb5922bac.gif#pic_center
SpringMVC—哀求传参
1. 通报对象
假如参数比较多时,方法声明就需要有很多形参;而且后续每次新增一个参数,也需要修改方法声明.
我们不妨把这些参数封装为一个对象;
Spring MVC 也可以自动实现对象参数的赋值,比如 Userinfo 对象:
https://i-blog.csdnimg.cn/direct/5745371e8d884304a7dbf7663b6c27f3.png
我们对 Userinfo 界说属性:name ,gender ,age,而且通过下列方式,重写 getter,setter,toString 方法:
https://i-blog.csdnimg.cn/direct/c4db945ba3ed4bf0b4a478d6f98cafdc.png
package com.example.springmvc_demo;
public class Userinfo {
private String name;
private Integer gender;
private Integer age;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Integer getGender() {
return gender;
}
public void setGender(Integer gender) {
this.gender = gender;
}
public Integer getAge() {
return age;
}
public void setAge(Integer age) {
this.age = age;
}
@Override
public String toString() {
return "Userinfo{" +
"name='" + name + '\'' +
", gender=" + gender +
", age=" + age +
'}';
}
}
通报对象代码实现:
https://i-blog.csdnimg.cn/direct/28acb15c95e7462298901e93c5acf6be.png
我们启动程序,通过 Postman 构造哀求:
https://i-blog.csdnimg.cn/direct/a777a2d960c44f6a800e4c8583566627.png
https://i-blog.csdnimg.cn/direct/30a2e57dbbcd4e76966d0783cbb75f08.png
假如我们把属性的 Integer 设置成 int,而且不传值 (取消勾选),也不会报错,默认为0;
https://i-blog.csdnimg.cn/direct/12cc9d6014ef4533ac77e89143d14fa5.png
我们在通报对象时,设置的属性名字,必须与后端代码中的对应属性的名字相同!
2. 后端参数重命名(后端参数映射)
某些特殊的情况下,前端通报的参数 key 和我们后端接收的key可以不一致;
[*] 比如 前端 通报了一个 kw 给后端,而 后端 是使用 keyword 字段来接收的;
[*] 如许就会出现参数接收不到的情况;
[*] 假如出现这种情况,我们就可以使用@RequestParam来重命名前后端的参数值
具体示比方下,后端实现代码:
https://i-blog.csdnimg.cn/direct/0b46aa47423c4fd1b6aec18d5aa98166.png
使用 Postman 发送哀求并传参,通过传参结果我们可以知道,对于前端命名的 kw 是可以正确传参的:
https://i-blog.csdnimg.cn/direct/c3f1ae503d7b4ac0b4257ca38d28d9b0.png
但是,假如我们使用后端命名的 keyword ,则无法传参:
https://i-blog.csdnimg.cn/direct/78e4225535b34e0ebebd1bc7a71ceef1.png
我们查看错误日志:
https://i-blog.csdnimg.cn/direct/674aebc85f6748ee89d1a6e4e14d592b.png
报错信息的意思是:方法参数类型的所需哀求参数‘kw’不存在
因此,我们加了注解 @RequestParam("kw") 后, kw 这个参数就是必须通报的了;
但是我们刚刚在 Postman 构造哀求时,并没有使用 kw 参数,keyword 是前端的 kw 赋值的,而不是r6 方法中,传入的参数 keyword ;
https://i-blog.csdnimg.cn/direct/c035c245ea4f45f4adb79a7091261568.png
结论:
[*] 使用 @RequestParam 进行参数重命名时,哀求参数只能和 @RequestParam 声明的名称一致,才气进行参数绑定和赋值;
[*] 使用 @RequestParam 进行参数重命名时,参数就变成了必传参数;
3. 非必传参数设置
假如我们的实际业务前端的参数是一个非必传的参数,针对上述题目,如何解决呢?
先来了解下参数必传的原因,我们查看@RequestParam 注解的实现细节,就可以发现端倪,注解实现如下:
https://i-blog.csdnimg.cn/direct/7559fc4e491c4b478bcc4afd09e5bc02.png
可以看到 required 的默认值为 true,表示含义就是:该注解修饰的参数默认为必传
既然如此,我们可以通过设置 @RequestParam 中的 required=false 来克制不通报时报错;
具体实现如下:
https://i-blog.csdnimg.cn/direct/1b1702dc187b4467a8e6cbb77b5885a7.png
可以看到,添加 required=false 之后,kw 前面也加了key,变成了 value =“kw”
注解属性赋值时,没有指明key的话,默认为 value 属性;
假如需要有多个属性进行赋值时,需要写上 key
重写运行程序,再次使用 Postman 发送哀求,相应结果的值固然为 null,但是没有报错:
https://i-blog.csdnimg.cn/direct/6c6e737d8bf94f91b0c062e944611822.png
4. 通报数组
Spring MVC可以自动绑定数组参数的赋值,后端实现代码:
https://i-blog.csdnimg.cn/direct/ab7d3469977746f0bd5bcf1e2b659f21.png
留意打印数组的 Arrays.toString(kunkunLike)
打开 Postman ,重新构造数组哀求:
https://i-blog.csdnimg.cn/direct/88e5b8e4e16c4b85a2864cd46658c912.png
也可以如许:
https://i-blog.csdnimg.cn/direct/2439295174134bf6b41c7a003cee53c9.png
5. 通报集合
https://i-blog.csdnimg.cn/direct/0c95ef3e6ef14d009433fd1b6c5c91aa.png
运行程序,使用 Postman 发送哀求:
https://i-blog.csdnimg.cn/direct/747ab09b33da489fbdfb233f9bbeea2c.png
说明假如要通报集合,我们的后端代码是不可以如许写的;
我们查看错误日志:
https://i-blog.csdnimg.cn/direct/07b6f7a3d1d9413aafe550dff68f4980.png
错误日志的意思是:没有为接口java.util.List找到主要的或唯一的构造函数
但是错误日志并不是根本原因,要想解决题目,通报参数,我们就需要使用@RequestParam绑定参数关系
集合参数:
[*]和数组类似,同一个哀求参数名有为多个,且需要使用@RequestParam绑定参数关系
[*] 默认情况下,哀求中参数名相同的多个值,是封装到数组;
[*] 假如要封装到集合,要使用@RequestParam绑定参数关系
哀求方式和数组类似:
https://i-blog.csdnimg.cn/direct/853ad77b1d2b4d6f83d3e4850e9fc68c.png
https://i-blog.csdnimg.cn/direct/8f60c480ab2d4348a521b7a08d501fd8.png
https://i-blog.csdnimg.cn/direct/a9d3553301c848ff9cad6aa4116248ea.gif#pic_center
https://i-blog.csdnimg.cn/direct/cd5abfb0ba1c49128b69f4ebb5922bac.gif#pic_center
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
页:
[1]