千家信息网

Spring Boot怎么实现请求参数校验

发表于:2026-11-01 作者:千家信息网编辑
千家信息网最后更新 2026年11月01日,这篇文章主要介绍了Spring Boot怎么实现请求参数校验的相关知识,内容详细易懂,操作简单快捷,具有一定借鉴价值,相信大家阅读完这篇Spring Boot怎么实现请求参数校验文章都会有所收获,下面
千家信息网最后更新 2026年11月01日Spring Boot怎么实现请求参数校验

这篇文章主要介绍了Spring Boot怎么实现请求参数校验的相关知识,内容详细易懂,操作简单快捷,具有一定借鉴价值,相信大家阅读完这篇Spring Boot怎么实现请求参数校验文章都会有所收获,下面我们一起来看看吧。

JSR-303

在开始动手实践之前,我们先了解一下接下来我们将使用的一项标准规范:JSR-303

什么是JSR?

JSR是Java Specification Requests的缩写,意思是Java 规范提案。是指向JCP(Java Community Process)提出新增一个标准化技术规范的正式请求。任何人都可以提交JSR,以向Java平台增添新的API和服务。JSR已成为Java界的一个重要标准。

JSR-303定义的是什么标准?

JSR-303 是JAVA EE 6 中的一项子规范,叫做Bean Validation,Hibernate Validator 是 Bean Validation 的参考实现 . Hibernate Validator 提供了 JSR 303 规范中所有内置 constraint 的实现,除此之外还有一些附加的 constraint。

Bean Validation中内置的constraint

Hibernate Validator附加的constraint

在JSR-303的标准之下,我们可以通过上面这些注解,优雅的定义各个请求参数的校验。更多关于JSR的内容可以参与官方文档或参考资料中的引文[1]。

动手实践

已经了解了JSR-303之后,接下来我们就来尝试一下,基于此规范如何实现参数的校验!

准备工作

读者可以拿任何一个使用Spring Boot 2.x构建的提供RESTful API的项目作为基础。也可以使用Spring Boot 2.x基础教程:使用Swagger2构建强大的API文档中构建的实验工程作为基础,您可以通过下面仓库中的chapter2-2目录取得:

  • Github:https://github.com/dyc87112/SpringBoot-Learning/tree/2.x

  • Gitee:https://gitee.com/didispace/SpringBoot-Learning/tree/2.x

当然,您也可以根据前文再构建一个作为复习,也是完全没有问题的。

快速入门

我们先来做一个简单的例子,比如:定义字段不能为Null。只需要两步

第一步:在要校验的字段上添加上@NotNull注解,具体如下:

@Data@ApiModel(description="用户实体")public class User {    @ApiModelProperty("用户编号")    private Long id;    @NotNull    @ApiModelProperty("用户姓名")    private String name;    @NotNull    @ApiModelProperty("用户年龄")    private Integer age;}

第二步:在需要校验的参数实体前添加@Valid注解,具体如下:

@PostMapping("/")@ApiOperation(value = "创建用户", notes = "根据User对象创建用户")public String postUser(@Valid @RequestBody User user) {    users.put(user.getId(), user);    return "success";}

完成上面配置之后,启动应用,并用POST请求访问localhost:8080/users/接口,body使用一个空对象,{}。你可以用Postman等测试工具发起,也可以使用curl发起,比如这样:

curl -X POST \  http://localhost:8080/users/ \  -H 'Content-Type: application/json' \  -H 'Postman-Token: 72745d04-caa5-44a1-be84-ba9c115f4dfb' \  -H 'cache-control: no-cache' \  -d '{    }'

不出意外,你可以得到如下结果:

{    "timestamp": "2019-10-05T05:45:19.221+0000",    "status": 400,    "error": "Bad Request",    "errors": [        {            "codes": [                "NotNull.user.age",                "NotNull.age",                "NotNull.java.lang.Integer",                "NotNull"            ],            "arguments": [                {                    "codes": [                        "user.age",                        "age"                    ],                    "arguments": null,                    "defaultMessage": "age",                    "code": "age"                }            ],            "defaultMessage": "不能为null",            "objectName": "user",            "field": "age",            "rejectedValue": null,            "bindingFailure": false,            "code": "NotNull"        },        {            "codes": [                "NotNull.user.name",                "NotNull.name",                "NotNull.java.lang.String",                "NotNull"            ],            "arguments": [                {                    "codes": [                        "user.name",                        "name"                    ],                    "arguments": null,                    "defaultMessage": "name",                    "code": "name"                }            ],            "defaultMessage": "不能为null",            "objectName": "user",            "field": "name",            "rejectedValue": null,            "bindingFailure": false,            "code": "NotNull"        }    ],    "message": "Validation failed for object='user'. Error count: 2",    "path": "/users/"}

其中返回内容的各参数含义如下:

  • timestamp:请求时间

  • status:HTTP返回的状态码,这里返回400,即:请求无效、错误的请求,通常参数校验不通过均为400

  • error:HTTP返回的错误描述,这里对应的就是400状态的错误描述:Bad Request

  • errors:具体错误原因,是一个数组类型;因为错误校验可能存在多个字段的错误,比如这里因为定义了两个参数不能为Null,所以存在两条错误记录信息

  • message:概要错误消息,返回内容中很容易可以知道,这里的错误原因是对user对象的校验失败,其中错误数量为2,而具体的错误信息就定义在上面的errors数组中

  • path:请求路径

请求的调用端在拿到这个规范化的错误信息之后,就可以方便的解析并作出对应的措施以完成自己的业务逻辑了。

尝试一些其他校验

在完成了上面的例子之后,我们还可以增加一些校验规则,比如:校验字符串的长度、校验数字的大小、校验字符串格式是否为邮箱等。下面我们就来定义一些复杂的校验定义,比如:

@Data@ApiModel(description="用户实体")public class User {    @ApiModelProperty("用户编号")    private Long id;    @NotNull    @Size(min = 2, max = 5)    @ApiModelProperty("用户姓名")    private String name;    @NotNull    @Max(100)    @Min(10)    @ApiModelProperty("用户年龄")    private Integer age;    @NotNull    @Email    @ApiModelProperty("用户邮箱")    private String email;}

发起一个可以出发name、age、email都校验不通过的请求,比如下面这样:

curl -X POST \  http://localhost:8080/users/ \  -H 'Content-Type: application/json' \  -H 'Postman-Token: 114db0f0-bdce-4ba5-baf6-01e5104a68a3' \  -H 'cache-control: no-cache' \  -d '{    "name": "abcdefg",    "age": 8,    "email": "aaaa"}'

我们将得到如下的错误返回:

{    "timestamp": "2019-10-05T06:24:30.518+0000",    "status": 400,    "error": "Bad Request",    "errors": [        {            "codes": [                "Size.user.name",                "Size.name",                "Size.java.lang.String",                "Size"            ],            "arguments": [                {                    "codes": [                        "user.name",                        "name"                    ],                    "arguments": null,                    "defaultMessage": "name",                    "code": "name"                },                5,                2            ],            "defaultMessage": "个数必须在2和5之间",            "objectName": "user",            "field": "name",            "rejectedValue": "abcdefg",            "bindingFailure": false,            "code": "Size"        },        {            "codes": [                "Min.user.age",                "Min.age",                "Min.java.lang.Integer",                "Min"            ],            "arguments": [                {                    "codes": [                        "user.age",                        "age"                    ],                    "arguments": null,                    "defaultMessage": "age",                    "code": "age"                },                10            ],            "defaultMessage": "最小不能小于10",            "objectName": "user",            "field": "age",            "rejectedValue": 8,            "bindingFailure": false,            "code": "Min"        },        {            "codes": [                "Email.user.email",                "Email.email",                "Email.java.lang.String",                "Email"            ],            "arguments": [                {                    "codes": [                        "user.email",                        "email"                    ],                    "arguments": null,                    "defaultMessage": "email",                    "code": "email"                },                [],                {                    "defaultMessage": ".*",                    "codes": [                        ".*"                    ],                    "arguments": null                }            ],            "defaultMessage": "不是一个合法的电子邮件地址",            "objectName": "user",            "field": "email",            "rejectedValue": "aaaa",            "bindingFailure": false,            "code": "Email"        }    ],    "message": "Validation failed for object='user'. Error count: 3",    "path": "/users/"}

从errors数组中的各个错误明细中,知道各个字段的defaultMessage,可以看到很清晰的错误描述。

Swagger文档中的体现

可能有读者会问了,我的接口中是定了这么多。上一篇教程中,不是还教了如何自动生成文档么,那么对于参数的校验逻辑该如何描述呢?

这里要分两种情况,Swagger自身对JSR-303有一定的支持,但是支持的并那么完善,并没有覆盖所有的注解的。

比如,上面我们使用的注解是可以自动生成的,启动上面我们的实验工程,然后访问http://localhost:8080/swagger-ui.html,在Models不是,我们可以看到如下图所示的内容:

其中:name和age字段相比上一篇教程中的文档描述,多了一些关于校验相关的说明;而email字段则没有体现相关校验说明。目前,Swagger共支持以下几个注解:@NotNull、@Max、@Min、@Size、@Pattern。在实际开发过程中,我们需要分情况来处理,对于Swagger支自动生成的可以利用原生支持来产生,如果有部分字段无法产生,则可以在@ApiModelProperty注解的描述中他,添加相应的校验说明,以便于使用方查看。

番外:也许你会有这些疑问

当请求参数校验出现错误信息的时候,错误格式可以修改吗?

答案是肯定的。这里的错误信息实际上由Spring Boot的异常处理机制统一组织并返回的,我们将在后面的教程中详细介绍,Spring Boot是如何统一处理异常返回以及我们该如何定时异常返回。

spring-boot-starter-validation是必须的吗?

有读者之前问过,看到很多教程都写了还要引入spring-boot-starter-validation依赖,这个依赖到底是否需要?(本篇中并没有引入)

    org.springframework.boot    spring-boot-starter-validation

其实,只需要仔细看一下spring-boot-starter-validation依赖主要是为了引入了什么,再根据当前自己使用的Spring Boot版本来判断即可。实际上,spring-boot-starter-validation依赖主要是为了引入下面这个依赖:

   org.hibernate.validator    hibernate-validator    6.0.14.Final    compile

我们可以看看当前工程的依赖中是否有它,就可以判断是否还需要额外引入。在Spring Boot 2.1版本中,该依然其实已经包含在了spring-boot-starter-web依赖中,并不需要额外引入,所以您在本文中找不到这一步。

关于"Spring Boot怎么实现请求参数校验"这篇文章的内容就介绍到这里,感谢各位的阅读!相信大家对"Spring Boot怎么实现请求参数校验"知识都有一定的了解,大家如果还想学习更多知识,欢迎关注行业资讯频道。

错误 参数 用户 字段 注解 内容 信息 教程 文档 标准 支持 基础 实体 实际 对象 工程 数组 知识 自动生成 读者 数据库的安全要保护哪些东西 数据库安全各自的含义是什么 生产安全数据库录入 数据库的安全性及管理 数据库安全策略包含哪些 海淀数据库安全审计系统 建立农村房屋安全信息数据库 易用的数据库客户端支持安全管理 连接数据库失败ssl安全错误 数据库的锁怎样保障安全 云南咖啡 互联网黑科技 百单网互联网科技有限公司 科技金融是不是互联网金融 A股互联网金融科技公司 佰商互联网科技有限公司 互联网科技有限公司 翻译 四个字互联网科技公司取名 广州慧亚互联网科技怎么样 顶级互联网科技成果有哪些 浙南科技城互联网大厦建设工程 玉溪新华互联网科技好不好 南博望互联网科技有限公司 无锡工业互联网科技有限公司 伍佰万互联网科技怎么赚钱 互联网营销推广黑科技 互联网科技包装股份有限公司上市 互联网科技企业商标注意事项 北京天晋互联网科技有限公司 10位科技互联网大佬 美国互联网保险保险科技 互联网与未来科技 苏州互联网科技贷款公司 广州凡科互联网科技 互联网 视角下的科技创新 南山科技园互联网公司有哪些 呼和浩特新华互联网科技学院 广州燕处互联网科技有限公司 广州智享互联网科技 互联网科技创新创业项目
0