# spring-boot-validation-demo

**Repository Path**: linzm1007/spring-boot-validation-demo

## Basic Information

- **Project Name**: spring-boot-validation-demo
- **Description**: spring-boot-validation-demo demo介绍了一下springboot请求入参的字符串非空和数值非空、范围校验
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2022-10-16
- **Last Updated**: 2022-10-28

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# web post get

## HTTP 请求方法

OPTIONS：返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送’*'的请求来测试服务器的性能
HEAD：类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头
GET：请求指定的页面信息，并返回实体主体
POST：向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的创建和/或已有资源的修改
PUT：从客户端向服务器上传最新内容
DELETE：请求服务器删除指定的页面
TRACE：回显服务器收到的请求，主要用于测试或诊断
CONNECT：HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器

什么是GET和POST
广义的理解其实就是数据请求的两种方式，区别的也基本人尽可之
1.GET在浏览器回退时是无害的，而POST会再次提交请求。
2.GET产生的URL地址可以被Bookmark，而POST不可以。
3.GET请求会被浏览器主动cache，而POST不会，除非手动设置。
4.GET请求只能进行url编码，而POST支持多种编码方式。
5.GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
6.GET请求在URL中传送的参数是有长度限制的，而POST么有。
7.对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
8.GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
9.**GET参数通过URL传递，POST放在Request body中**
GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。

这样回答也没错，但你这样的回答其实只能说明你没有get到面试官真正的意图
我们抛开两者的不同来看，其实从出发点上来说他们本质相同的一种东西
依附的都是`http`

```
而HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。
```

但GET和POST 其实还有一个隐式的最大区别 ：**GET产生一个TCP数据包；POST产生两个TCP数据包**。
这才是核心的区别所在！！！
造成这一现象的原因呢，其实就是浏览器接受响应的处理方式造成的

```
对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）
```

使用技巧的区别

GET与POST都有自己的语义，不能随便混用。

在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。

并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。什么是幂等性

HTTP/1.1中对幂等性的定义是：一次和多次请求某一个资源**对于资源本身**应该具有同样的结果（网络超时等问题除外）。也就是说，**其任意多次执行对资源本身所产生的影响均与一次执行的影响相同**。

> Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.

这里需要关注几个重点：

1. 幂等不仅仅只是一次（或多次）请求对资源没有副作用（比如查询数据库操作，没有增删改，因此没有对数据库有任何影响）。
2. 幂等还包括第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。
3. 幂等关注的是以后的多次请求是否对资源产生的副作用，而不关注结果。
4. 网络超时等问题，不是幂等的讨论范围。

幂等性是系统服务对外一种承诺（而不是实现），承诺只要调用接口成功，外部多次调用对系统的影响是一致的。声明为幂等的服务会认为外部调用失败是常态，并且失败之后必然会有重试。

## 什么情况下需要幂等

业务开发中，经常会遇到重复提交的情况，无论是由于网络问题无法收到请求结果而重新发起请求，或是前端的操作抖动而造成重复提交情况。 在交易系统，支付系统这种重复提交造成的问题有尤其明显，比如：

1. 用户在APP上连续点击了多次提交订单，后台应该只产生一个订单；
2. 向支付宝发起支付请求，由于网络问题或系统BUG重发，支付宝应该只扣一次钱。 **很显然，声明幂等的服务认为，外部调用者会存在多次调用的情况，为了防止外部多次调用对系统数据状态的发生多次改变，将服务设计成幂等。**

## 幂等VS防重

上面例子中小明遇到的问题，只是重复提交的情况，和服务幂等的初衷是不同的。重复提交是在第一次请求已经成功的情况下，人为的进行多次操作，导致不满足幂等要求的服务多次改变状态。而幂等更多使用的情况是第一次请求不知道结果（比如超时）或者失败的异常情况下，发起多次请求，目的是多次确认第一次请求成功，却不会因多次请求而出现多次的状态变化。

## 什么情况下需要保证幂等性

以SQL为例，有下面三种场景，只有第三种场景需要开发人员使用其他策略保证幂等性：

1. `SELECT col1 FROM tab1 WHER col2=2`，无论执行多少次都不会改变状态，是天然的幂等。
2. `UPDATE tab1 SET col1=1 WHERE col2=2`，无论执行**成功**多少次**状态**都是一致的，因此也是幂等操作。
3. `UPDATE tab1 SET col1=col1+1 WHERE col2=2`，每次执行的结果都会发生变化，这种不是幂等的。

## 为什么要设计幂等性的服务

幂等可以使得客户端逻辑处理变得简单，但是却以服务逻辑变得复杂为代价。满足幂等服务的需要在逻辑中至少包含两点：

1. 首先去查询上一次的执行状态，如果没有则认为是第一次请求
2. 在服务改变状态的业务逻辑前，保证防重复提交的逻辑

## 幂等的不足

幂等是为了简化客户端逻辑处理，却增加了服务提供者的逻辑和成本，是否有必要，需要根据具体场景具体分析，因此除了业务上的特殊要求外，尽量不提供幂等的接口。

1. 增加了额外控制幂等的业务逻辑，复杂化了业务功能；
2. 把并行执行的功能改为串行执行，降低了执行效率。

## 保证幂等策略

幂等需要通过**唯一的业务单号**来保证。也就是说相同的业务单号，认为是同一笔业务。使用这个唯一的业务单号来确保，后面多次的相同的业务单号的处理逻辑和执行效果是一致的。 下面以支付为例，在不考虑并发的情况下，实现幂等很简单：①先查询一下订单是否已经支付过，②如果已经支付过，则返回支付成功；如果没有支付，进行支付流程，修改订单状态为‘已支付’。

## 防重复提交策略

上述的保证幂等方案是分成两步的，第②步依赖第①步的查询结果，无法保证原子性的。在高并发下就会出现下面的情况：第二次请求在第一次请求第②步订单状态还没有修改为‘已支付状态’的情况下到来。既然得出了这个结论，余下的问题也就变得简单：把查询和变更状态操作加锁，将并行操作改为串行操作。

### 乐观锁

如果只是更新**已有**的数据，没有必要对业务进行加锁，设计表结构时使用乐观锁，一般通过version来做乐观锁，这样既能保证执行效率，又能保证幂等。例如： `UPDATE tab1 SET col1=1,version=version+1 WHERE version=#version#` 不过，乐观锁存在失效的情况，就是常说的ABA问题，不过如果version版本一直是自增的就不会出现ABA的情况。（从网上找了一张图片很能说明乐观锁，引用过来，出自Mybatis对乐观锁的支持）

### 防重表

使用订单号orderNo做为去重表的唯一索引，每次请求都根据订单号向去重表中插入一条数据。第一次请求查询订单支付状态，当然订单没有支付，进行支付操作，无论成功与否，执行完后更新订单状态为成功或失败，删除去重表中的数据。后续的订单因为表中唯一索引而插入失败，则返回操作失败，直到第一次的请求完成（成功或失败）。**可以看出防重表作用是加锁的功能。**

### 分布式锁

这里使用的防重表可以使用分布式锁代替，比如Redis。订单发起支付请求，支付系统会去Redis缓存中查询是否存在该订单号的Key，如果不存在，则向Redis增加Key为订单号。查询订单支付已经支付，如果没有则进行支付，支付完成后删除该订单号的Key。通过Redis做到了分布式锁，只有这次订单订单支付请求完成，下次请求才能进来。相比去重表，将放并发做到了缓存中，较为高效。思路相同，**同一时间只能完成一次支付请求**。

### token令牌

这种方式分成两个阶段：申请token阶段和支付阶段。 第一阶段，在进入到提交订单页面之前，需要订单系统根据用户信息向支付系统发起一次申请token的请求，支付系统将token保存到Redis缓存中，为第二阶段支付使用。 第二阶段，订单系统拿着申请到的token发起支付请求，支付系统会检查Redis中是否存在该token，如果存在，表示第一次发起支付请求，删除缓存中token后开始支付逻辑处理；如果缓存中不存在，表示非法请求。 实际上这里的token是一个信物，支付系统根据token确认，你是你妈的孩子。不足是需要系统间交互两次，流程较上述方法复杂。

### 支付缓冲区

把订单的支付请求都快速地接下来，一个快速接单的缓冲管道。后续使用异步任务处理管道中的数据，过滤掉重复的待支付订单。优点是同步转异步，高吞吐。不足是不能及时地返回支付结果，需要后续监听支付结果的异步返回。

# @validated和@valid区别

在Controller中校验方法参数时，使用@Valid和@Validated并无特殊差异（若不需要分组校验的话）:
@Valid：标准JSR-303规范的标记型注解，用来标记验证属性和方法返回值，进行级联和递归校验
@Validated：Spring的注解，是标准JSR-303的一个变种（补充），提供了一个分组功能，可以在入参验证时，根据不同的分组采用不同的验证机制

方法级别：
@Validated注解可以用于类级别，用于支持Spring进行方法级别的参数校验。@Valid可以用在属性级别约束，用来表示级联校验。
@Validated只能用在类、方法和参数上，而@Valid可用于方法、字段、构造器和参数上

## 校验参数、级联属性

1、校验参数
当入参为实体对象时，需要在方法上加@Valid或@Validated或者在参数前加@Valid或@Validated，或者在类上加@Validated

@Valid
@GetMapping("/exam-info")
public Boolean getInfo(User user){......}

@GetMapping("/exam-info")
public Boolean getInfo(@Valid User user){......}

@Validated
@GetMapping("/exam-info")
public Boolean getInfo(User user){......}

@GetMapping("/exam-info")
public Boolean getInfo(@Validated User user){......}

public Class User{
@NotNull（"id不能为空"）
private Integer id;
}

2、嵌套验证
@valid作用于属性上有嵌套验证作用，@validated不能作用于属性上,如下代码在User类的属性car上添加@valid注解，当传参id为空时会报错。

@GetMapping("/exam-info")
public Boolean getInfo(@Valid User user){.....}

public class User{
@Valid
@NotNull("car不能为空")
private Car car;
}
public class Car{
@NotNull("id不能为空")
private Integer id;
}

## 校验List

@Valid只能校验JavaBean，而List不是JavaBean所以校验会失败，介绍三种解决办法

### 方法1：对List进行Wrapper

既然List不是JavaBean，那我们就把它封装成JavaBean，我们定义一个ListWrapper类如下：

import lombok.Getter;
import lombok.Setter;
import javax.validation.Valid;
import java.util.ArrayList;
import java.util.List;

@Setter
@Getter
public class ListWrapper {
@Valid
private List list;

```cpp
public ListWrapper() {
    list = new ArrayList<>();
}

public  ListWrapper(List<E> list) {
    this.list = list;
}
```

}
同时修改一下controller对应的方法：

```less
// 使用包装类对list进行验证
@PostMapping("/insert/all")
public ServerResponse<String> insertList(@Valid @RequestBody ListWrapper<UserEntity> listWrapper, BindingResult bindingResult) {
    if(bindingResult.hasErrors()) {
        log.error(bindingResult.getFieldError().toString());
        return ServerResponse.createByErrorMessage(bindingResult.getFieldError().getDefaultMessage());
    }

    userService.insertList(listWrapper.getList());
    return ServerResponse.createBySuccess();
}
```

这样就可以对list进行校验了

注意：

由于对list进行了包装，如果我们传参的时候

[{},{}..]要改为{“list”: [{},{}..]}

### 方法2：使用@Validated+@Valid

在controller类上面增加@Validated注解，并且删除方法参数中的BindingResult bindingResult（因为这个参数已经没有用了，异常统一有controller返回了）
![file](https://img2018.cnblogs.com/blog/1203146/201910/1203146-20191020211420133-1610773132.jpg)
![file](https://img2018.cnblogs.com/blog/1203146/201910/1203146-20191020211420374-216377822.jpg)

然后我们运行一下测试一下
![file](https://img2018.cnblogs.com/blog/1203146/201910/1203146-20191020211420610-766298745.jpg)

可以看到可以对参数进行校验了，但还还有一个问题，那就是这个不是我们想要的返回格式，它controller自己返回的格式，所以我们需要做一个统一异常处理，代码如下：

import com.wyq.firstdemo.common.ServerResponse;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.ResponseBody;
import org.springframework.web.bind.annotation.RestControllerAdvice;

import javax.validation.ConstraintViolation;
import javax.validation.ConstraintViolationException;
import java.util.Set;

@Slf4j
@RestControllerAdvice
public class ControllerExceptionHandler {

```typescript
@ExceptionHandler
@ResponseBody
public ServerResponse<String> handle(ConstraintViolationException exception) {
    log.error(String.valueOf(exception));
    Set<ConstraintViolation<?>> violations = exception.getConstraintViolations();
    StringBuilder builder = new StringBuilder();
    for (ConstraintViolation violation : violations) {
        builder.append(violation.getMessage());
        break;
    }
    return ServerResponse.createByErrorMessage(builder.toString());
}
```

}
经过统一异常处理，我们这边的返回结果就是我们想要的格式了
![file](https://img2018.cnblogs.com/blog/1203146/201910/1203146-20191020211420842-1046262713.jpg)

### 方法3：自定义一个List

先上代码后说明，先定义一个ValidList

import javax.validation.Valid;
import java.util.*;

public class ValidList implements List {

```cpp
@Valid
private List<E> list;

public ValidList() {
    this.list = new ArrayList<>();
}

public ValidList(List<E> list) {
    this.list = list;
}

public List<E> getList() {
    return list;
}

public void setList(List<E> list) {
    this.list = list;
}

@Override
public int size() {
    return list.size();
}

@Override
public boolean isEmpty() {
    return list.isEmpty();
}

...
```

}
对比方法3和方法1，有没有觉得代码有点相似，新建一个类，并且让他实现List接口，使这个类即具有了JavaBean的特性，又具有了List的特性，比方法1简单优雅很多。

只需要把List换成ValidList就可以了，还不需要多统一异常处理。
![file](https://img2018.cnblogs.com/blog/1203146/201910/1203146-20191020211421066-680366473.jpg)
https://www.cnblogs.com/king0207/p/14333921.html