关于@RequestBody无法获取boolean类型请求参数的解决思路

超、凢脫俗 2023-10-11 19:08 36阅读 0赞

这篇是过年前的最后一篇博客，同样也是对在平常开发过程中对遇到的坑进行总结。不知道大家在用java写后台接口与前端联调时有没有遇到过这个坑，就是我使用@RequestBody来修饰AddUpdateDecisionFlowRequestVo对象进而来接收前端的请求时，AddUpdateDecisionFlowRequestVo对象里面的isStart这个boolean类型的变量是没有接收到任何值的，如下图所示：

![在这里插入图片描述][3b773d3dc8562f6ad86c66314def04cb.png]

![在这里插入图片描述][eb817b9532ff141caf0eb57bdfb07f2f.png]

从上图可看到，怎么好端端的isStart请求参数变成了start了呢，从网上google了下，发现有这么一段话：

【强制】POJO 类中布尔类型的变量，都不要加 is，否则部分框架解析会引起序列化错误。反例：定义为基本数据类型 Boolean isDeleted；的属性，它的方法也是isDeleted()，RPC框架在反向解析的时候，“以为”对应的属性名称是deleted，导致属性获取不到，进而抛出异常。

可见后端在将前端请求的json数据反序列化为对象时误将isStart这个字段转化为start，从而导致后端接收不到isStart这个变量的值。分析完原因后，那么该如何解决呢？其实很简单，在isStart这个变量上面加上@JsonPerperty(“isStart”)这样的注解就可以了，如下代码所示：

经过一请求，发现还真得可以了！

那么 @JsonProperty和@JsonAlias这两个注解有什么区别呢？如下所示：

@JsonProperty

这个注解提供了序列化和反序列化过程中该java属性所对应的名称

@JsonAlias

这个注解只在反序列化时起作用，指定该java属性可以接受的更多名称

其实开发过程中经常踩坑未必是坏事，只要你能够及时去总结并且纠正，下次就会避免踩到同样的坑！希望大家在平常开发过程中养成一个总结的好习惯。

[3b773d3dc8562f6ad86c66314def04cb.png]: https://img-blog.csdnimg.cn/img_convert/3b773d3dc8562f6ad86c66314def04cb.png
[eb817b9532ff141caf0eb57bdfb07f2f.png]: https://img-blog.csdnimg.cn/img_convert/eb817b9532ff141caf0eb57bdfb07f2f.png