使用@RequestBody注解踩的坑

一、问题由来

最近在和前端调试一个自己写的接口时，频频出现问题，让我很是烦恼。因此写下这篇博文来记录开发中遇到的一些问题。第一个问题是

前端页面传递参数后，后台不能正常接收参数。我写好接口以后，通过swagger测试，发现没问题，然后就和前端进行调试，可是前端进

行调试时频频出错。Controller的代码如下，

使用Swagger工具调试接口时，也没有问题。因为文件是存放在测试环境上面的，所以报了一个文件不存在是正确的。

可问题是前端测试时报的确实另外一个错，文件ID不存在，这个错误也是自己主动抛出的异常。这就很尴尬了。

二、问题分析

经过反复的排查，发现有一个地方存在问题，那就是参数的传递方式不一样。前端开发人员传递参数时的方式是Request Payload，而我在使用Swagger测试时

传递参数的方式为Form Data。因为这一不同导致了BUG的出现，问题找到了，我想应该会比较好解决。

三、解决方案

发现这个问题，我立马和前端人员协商，看看是他修改还是我修改。去看了之前已经做好的一些功能，想看看使用Post请求传递参数的方式是什么。

结果发现也是Request Payload这种方式，Controller中也是使用PostMapping。接着我开始修改后台代码，修改后的代码如下，

使用Swagger测试情况如下，测试正常。部署到测试服务器时，数据也正确返回了。

我本以为现在应该没问题了，测试也正常了。可是前端测试人员给我反馈，还是不行没有数据返回，返回的错误信息是没有没有查询到文件。

我让他把传递的参数单独发给我，我直接去数据库中查询，发现有数据，这就奇了怪了。

为什么我在本地测试时，查询没问题，前端人员使用前端项目访问时就出问题呢？只得继续排查。让前端人员调试时直接连接我的后台，打断点进行调试。

这是发现问题:使用这种方式，public ResponseEntity<JsonResult<String>> previewExcel(@RequestBody String fileId){}接收到的参数不是我

想要的，接收到的fileId的值为: "fileid:'379ecdefeed5468c845f1984fc26f78c'"，就相当于把传递进来的整个JSON数据映射到fileId上了，而并不是仅仅是后

面的值。确定这个问题后，我修改了代码将@RequestBody后面的单个变量修改为一个参数输入的类如下。

然后再次调试，结果如下。变化是参数的传递方式还是Request Payload，但是里面的参数变为JSON格式的数据了。然后将代码部署到测试环境，前端人员测试时正确，问题解决。

以前开发时，还真没有注意这些细节问题。Controller中使用不同的注解，传递参数的方式也会不一样。同时也对于@RequestBody注解有了更深刻的理解。

这个注解是将Post请求中的JSON数据映射到一个类中，不能单独映射到某个字段中，即使是单个字段最好也是使用请求输入类来接收收据。吃一堑,长一智，

通过这次采坑，又学习到不少东西。