Spring之RequestBody的使用姿势小结

简介: SpringMVC中处理请求参数有好几种不同的方式,如我们常见的下面几种根据 HttpServletRequest 对象获取根据 @PathVariable 注解获取url参数根据 @RequestParam 注解获取请求参数根据Bean的方式获取请求参数根据 @ModelAttribute 注解获取请求参数

image.png


SpringMVC中处理请求参数有好几种不同的方式,如我们常见的下面几种


  • 根据 HttpServletRequest 对象获取
  • 根据 @PathVariable 注解获取url参数
  • 根据 @RequestParam 注解获取请求参数
  • 根据Bean的方式获取请求参数
  • 根据 @ModelAttribute 注解获取请求参数


对上面几种方式有兴趣的可以看一下这篇博文: SpringMVC之请求参数的获取方式


除了上面的几种方式之外,还有一种 @RequestBody 的使用方式,本文则主要介绍这种传参的使用姿势和相关注意事项


I. 使用姿势



1. 服务接口




借助Spring框架,使用@RequestBody并没有什么难度,很简单的就可以写一个使用case出来,如下


@Slf4j
@RestController
public class ReqBodyController {
    @Data
    @NoArgsConstructor
    @AllArgsConstructor
    public static class Req {
        private String key;
        private Integer size;
    }
    @RequestMapping(value = "/body", method = {RequestMethod.POST, RequestMethod.GET, RequestMethod.OPTIONS})
    public BaseRsp body(@RequestBody Req req) {
        log.info("req: {}", req);
        return new BaseRsp<>(req);
    }
}
复制代码


看上面的实现,和我们通常的写法并无差别,无非是将以前的 @RequsetParam 注解换成 @RequsetBody 注解,而且这个注解内部只有一个filed,比RequsetParam还少


@Target({ElementType.PARAMETER})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface RequestBody {
    // 默认参数必须存在,否则会抛一个异常
    boolean required() default true; 
}
复制代码


看到上面的实现,估计也可以猜出,这个注解对于后端而言,写没啥问题,关键是如何用(具体来讲是如何给前端用)


2. 接口调用



上面写完了,接下来的重点就是如何使用了,在使用之前,有必要了解下 RequestBody 这个注解出现的原有以及应用场景(换句话说它和RequestParam有什么区别,为什么要单独的搞一个这个东西出来)


RequestBody


@requestBody注解常用来处理content-type不是默认的application/x-www-form-urlcoded编码的内容,比如说:application/json或者是application/xml等。一般情况下来说常用其来处理application/json类型。


a. content-type定义


在进入下一步之前,有必要说一下Content-Type这个http请求头的作用了,下面一段来自其他博文,原文链接见最后


MediaType,即是Internet Media Type,互联网媒体类型;也叫做MIME类型,在Http协议消息头中,使用Content-Type来表示具体请求中的媒体类型信息。


常见媒体格式如下:


  • text/html : HTML格式
  • text/plain :纯文本格式
  • text/xml :  XML格式
  • image/gif :gif图片格式
  • image/jpeg :jpg图片格式
  • image/png:png图片格式


以application开头的媒体格式类型:


  • application/xhtml+xml :XHTML格式
  • application/xml     : XML数据格式
  • application/atom+xml  :Atom XML聚合格式
  • application/json    : JSON数据格式
  • application/pdf       :pdf格式
  • application/msword  : Word文档格式
  • application/octet-stream : 二进制流数据(如常见的文件下载)
  • application/x-www-form-urlencoded : 中默认的encType,form表单数据被编码为key/value格式发送到服务器(表单默认的提交数据的格式)


b. content-type 实例说明


上面算是基本定义和取值,下面结合实例对典型的几种方式进行说明


  • application/x-www-form-urlencoded:数据被编码为名称/值对。这是标准的编码格式。
  • multipart/form-data: 数据被编码为一条消息,页上的每个控件对应消息中的一个部分。
  • text/plain: 数据以纯文本形式(text/json/xml/html)进行编码,其中不含任何控件或格式字符


对于前端使用而言,form表单的enctype属性为编码方式,常用有两种:

application/x-www-form-urlencodedmultipart/form-data,默认为application/x-www-form-urlencoded


Get请求


发起Get请求时,浏览器用application/x-www-form-urlencoded方式,将表单数据转换成一个字符串(key1=value1&key2=value2...)拼接到url上,这就是我们常见的url带请求参数的情况


Post表单


发起post请求时,如果没有传文件,浏览器也是将form表单的数据封装成k=v的结果丢到http body中,拿开源中国的博客提交的表单为例,一个典型的post表单,上传的数据拼装在form data中,为kv结构


image.png

如果有传文件的场景,Content-Type类型会升级为multipart/form-data,这一块不详细展开,后面有机会再说


Post json串


post表单除了前面一种方式之外,还有一种也是我们常见的,就是讲所有的表单数据放在一个大的json串中,然后丢给后端,这里也有一个在线的实例,某电商平台的商品发表,截图如下


image.png


注意看上面的Request Payload,是一个大的json串,和前面差别明显


c. RequestBody请求


根据RequestBody的定义,要想访问前面定义的那个接口,使用传统的表单传递方式是不行的,curl命令测试如下


curl -X POST -d 'key=haha&size=123' http://127.0.0.1:19533/body
复制代码


后端对应的输出如下(抛了一个异常,表示@RequestBody注解修饰rest接口,不支持 Content type 'application/x-www-form-urlencoded;charset=UTF-8'

image.png


因此使用姿势需要显示添加请求头,传参也改变一下

curl -l -H "Content-type: application/json" -X GET -d '{"key": "!23", "size": 10}' http://127.0.0.1:19533/body
复制代码


返回结果如下

image.png


3. 注意事项



a. content-type显示指定


根据前面的说明,可以知道 @RequestBody 这个注解的使用,使得REST接口接收的不再content-type为application/x-www-form-urlencoded的请求, 反而需要显示指定为application/json


b. 请求方法


RequestBody支持GET方法么?前面都是采用post提交参数,如果改成GET会怎样?


curl测试方式

curl -l -H "Content-type: application/json" -X GET -d '{"key": "!23", "size": 10}' http://127.0.0.1:19533/body\?key\=app
复制代码


对应的后端debug截图如下,发现使用GET方式,并没有问题,依然可以获取到参数


image.png


换成大名鼎鼎的POSTMAN来测试


使用post方法请求时,截图如下,主要就是修改header的content-type,然后在body中添加json串格式的请求

image.png


然而改成get之后,body都直接灰掉了,也就是它不支持在get请求时,提交Body数据

image.png


url请求方式


接下来直接换成url的请求方式,看是否直接支持get请求

http://127.0.0.1:19533/body?{"key": "!23", "size": 10}
复制代码


浏览器中输入时,服务器400, 换成curl方式请求,抛的是缺少RequestBody的异常,也就是说,将json串拼接到url中貌似不行(也有可能是我的使用姿势不对。。。)


小结

  • 到这里小结一下,使用RequestBody获取参数时,还是老老实实的选择POST方法比较合适,至于原因,跟大众,随主流,跟着大家的习惯走比较好


c. 参数获取


这个主要就是后端编写接口时,获取RequestBody参数的问题了,通过测试,发现在HttpServletRequest参数中,居然拿不到提交的RequestBody参数,演示如下

请求url为


curl -l -H "Content-type: application/json" -X POST -d '{"key": "!23", "size": 10}' http://127.0.0.1:19533/body\?url\=ddd
复制代码


对应的debug截图如下,url参数可以拿到,RequestBody参数没有


image.png


首先声明,下面的这段分析,没有看源码,纯属于个人推断,如有问题,对被误导的朋友表示歉意,也希望对此有了解的朋友,多多批评指正


从传文件的思路出发,前端传文件给后端时,后端是基于流的方式,将上传的二进制流,写入到`MultipartFile`;而二进制流读完之后,没法再重复的读
RequestBody可能也是这么个逻辑,首先是从HttpServletRequest的Reader流中读取body参数并封装到上面的req对象,而不会像url参数一样,写回到`javax.servlet.ServletRequest#getParameterMap`
复制代码


对上面的猜测做一个小小的验证,改成直接从HttpServletRequest的Reader流中获取请求body参数

@RequestMapping(value = "/body", method = {RequestMethod.POST, RequestMethod.GET, RequestMethod.OPTIONS})
public BaseRsp body(HttpServletRequest request) throws IOException {
    BufferedReader reader = request.getReader();
    StringBuilder builder = new StringBuilder();
    String line = reader.readLine();
    while (line != null) {
        builder.append(line);
        line = reader.readLine();
    }
    reader.close();
    String reqBody = builder.toString();
    Req req = JSON.parseObject(reqBody, Req.class);
    log.info("req: {}, request: {}", req, request.getParameterMap());
    return new BaseRsp<>(req);
}
复制代码


验证如下

image.png


其实到这里,有个有意思的地方已经引起了我的好奇,那就是在Spring容器中HttpServletRequest这个东西,是怎么运转的,后面有机会再聊,此处不展开...


4. 小结



  • ReuqestBody 主要是处理json串格式的请求参数,要求使用方指定header content-type:application/json
  • RequestBody 通常要求调用方使用post请求
  • RequsetBody参数,不会放在HttpServletRequest的Map中,因此没法通过javax.servlet.ServletRequest#getParameter获取



目录
打赏
0
0
0
0
13
分享
相关文章
Spring @RequestBody与@ResponseBody注解
Spring的注解非常多,这篇文章我们说一下它的@RequestBody 和 @ResponseBody注解。 @ResponseBody 简单说,@ResponseBody注解将HttpRequest的请求体映射为Java的POJO对象。
Spring MVC常用注解--“姐妹花”@RequestBody和@ResponseBody
在这篇短文中,我们简要地介绍了Spring MVC中常用的注解 @RequestBody和@ResponseBody。
2636 0
详细介绍SpringBoot启动流程及配置类解析原理
通过对 Spring Boot 启动流程及配置类解析原理的深入分析,我们可以看到 Spring Boot 在启动时的灵活性和可扩展性。理解这些机制不仅有助于开发者更好地使用 Spring Boot 进行应用开发,还能够在面对问题时,迅速定位和解决问题。希望本文能为您在 Spring Boot 开发过程中提供有效的指导和帮助。
46 12
SpringBoot项目打包成war包
通过上述步骤,我们成功地将一个Spring Boot应用打包成WAR文件,并部署到外部的Tomcat服务器中。这种方式适用于需要与传统Servlet容器集成的场景。
30 8
Spring Boot 两种部署到服务器的方式
本文介绍了Spring Boot项目的两种部署方式:jar包和war包。Jar包方式使用内置Tomcat,只需配置JDK 1.8及以上环境,通过`nohup java -jar`命令后台运行,并开放服务器端口即可访问。War包则需将项目打包后放入外部Tomcat的webapps目录,修改启动类继承`SpringBootServletInitializer`并调整pom.xml中的打包类型为war,最后启动Tomcat访问应用。两者各有优劣,jar包更简单便捷,而war包适合传统部署场景。需要注意的是,war包部署时,内置Tomcat的端口配置不会生效。
306 17
Spring Boot 两种部署到服务器的方式
springboot自动配置原理
Spring Boot 自动配置原理:通过 `@EnableAutoConfiguration` 开启自动配置,扫描 `META-INF/spring.factories` 下的配置类,省去手动编写配置文件。使用 `@ConditionalXXX` 注解判断配置类是否生效,导入对应的 starter 后自动配置生效。通过 `@EnableConfigurationProperties` 加载配置属性,默认值与配置文件中的值结合使用。总结来说,Spring Boot 通过这些机制简化了开发配置流程,提升了开发效率。
78 17
springboot自动配置原理
SpringBoot集成Shiro权限+Jwt认证
本文主要描述如何快速基于SpringBoot 2.5.X版本集成Shiro+JWT框架,让大家快速实现无状态登陆和接口权限认证主体框架,具体业务细节未实现,大家按照实际项目补充。
99 11
Spring Boot 3 集成 Spring Security + JWT
本文详细介绍了如何使用Spring Boot 3和Spring Security集成JWT,实现前后端分离的安全认证概述了从入门到引入数据库,再到使用JWT的完整流程。列举了项目中用到的关键依赖,如MyBatis-Plus、Hutool等。简要提及了系统配置表、部门表、字典表等表结构。使用Hutool-jwt工具类进行JWT校验。配置忽略路径、禁用CSRF、添加JWT校验过滤器等。实现登录接口,返回token等信息。
499 12
最新版 | 深入剖析SpringBoot3源码——分析自动装配原理(面试常考)
自动装配是现在面试中常考的一道面试题。本文基于最新的 SpringBoot 3.3.3 版本的源码来分析自动装配的原理,并在文未说明了SpringBoot2和SpringBoot3的自动装配源码中区别,以及面试回答的拿分核心话术。
最新版 | 深入剖析SpringBoot3源码——分析自动装配原理(面试常考)
Spring Boot 如何测试打包部署
本文介绍了 Spring Boot 项目的开发、调试、打包及投产上线的全流程。主要内容包括: 1. **单元测试**:通过添加 `spring-boot-starter-test` 包,使用 `@RunWith(SpringRunner.class)` 和 `@SpringBootTest` 注解进行测试类开发。 2. **集成测试**:支持热部署,通过添加 `spring-boot-devtools` 实现代码修改后自动重启。 3. **投产上线**:提供两种部署方案,一是打包成 jar 包直接运行,二是打包成 war 包部署到 Tomcat 服务器。
50 10
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等