@RequestParam和@RequestBody的使用和区别&&使用@RequestParam和不使用@RequestParam的区别

RequestParam的使用

@RequestParam主要用于将请求参数区域的数据映射到控制层方法的参数上
首先我们需要知道@RequestParam注解主要有哪些参数

1. value：请求中传入参数的名称，如果不设置后台接口的value值，则会默认为该变量名。比如上图中第一个参数如果不设置value=“page”,则前端传入的参数名必须为pageNum,否则在后台接口中pageNum将接收不到对应的数据

2. required：该参数是否为必传项。默认是true，表示请求中一定要传入对应的参数，否则会报404错误，如果设置为false时，当请求中没有此参数，将会默认为null,而对于基本数据类型的变量，则必须有值，这时会抛出空指针异常。如果允许空值，则接口中变量需要使用包装类来声明。

3. defaultValue：参数的默认值，如果请求中没有同名的参数时，该变量默认为此值。注意默认值可以使用SpEL表达式，如"#{systemProperties[‘java.vm.version’]}"

使用@RequestParm用于绑定controller上的参数,可以是多个参数，也可以是一个Map集合，GET，POST均可

@RequestParm中name属性是指定参数名，required属性默认为ture，表示必传。若为false则为非必传。属性有defaultValue默认值选项，若该参数为null时，会将默认值填充到参数上。

要求

@RequestParam的要求
1. 均支持POST,GET请求
2. 只支持Content-Type: 为 application/x-www-form-urlencoded编码的内容。Http协议中，如果不指定Content-Type，则默认传递的参数就是application/x-www-form-urlencoded类型）
3.参数列表中的参数名称是大小写敏感的

在Spring中，如果在方法参数列表中使用@RequestParam标注多个参数，会让映射方法的可读性大大降低。

如果映射请求的参数只有一两个的话，使用@RequestParam会非常直观，但是如果参数列表越来越长，就很容易晕菜。

虽然我们不能直接在参数对象中使用@RequestParam标签，但是并不代表没有其他的办法。这篇文章就会演示怎么使用对象的封装来简化多个@RequestParams标签。

【注：SpringMVC注入请求参数到对象中，这个对于很多开发是再正常不过的，但是这里强调的是使用@RequestParam来绑定参数，因为@RequestParam可以对绑定参数有更多的限制】

场景一：

如果在请求中传入多个同名参数，比如：url?userName=zhl&userName=holley时怎么办？

其实此时传入的数据格式是：“zhl,holley”,即多个数据之间使用逗号分隔开，在后台接口中可以使用数组或者list类型的变量来接收：

public String requestparam8(@RequestParam(value=“userName”) String [] userNames)

或者

public String requestparam8(@RequestParam(value=“list”) List list)

场景二：

过长的@RequestParam列表
不管是controller还是其他的类，过长的参数列表会让代码的可读性变差，这一点是所有开发人员都认同的。更不要说，如果大量的参数的类型还是一致的情况下，参数就更容易混淆了。

很多代码检查工具，都会把方法的参数个数作为检查条件，也是因为过长的参数列表被认为是一种错误的代码规范。

常见的一种解决方案，就是把一组参数合并起来，并作为应用的独立的一层。常见的，这组参数可以合并到一个对象中，并给予这个对象一个恰当的名字即可。

我们来看一个GET请求服务端的例子：

@RestController
@RequestMapping("/products")
class ProductController {
   //...
   @GetMapping
   List<Product> searchProducts(@RequestParam String query,
                                @RequestParam(required = false, defaultValue = "0") int offset,
                                @RequestParam(required = false, defaultValue = "10") int limit) {
       return productRepository.search(query, offset, limit);
   }
}
1
2
3
4
5
6
7
8
9
10
11

虽然该方法只有三个参数，但是参数列表很容易增长的，比如既然代码中是查询商品服务，那么常常需要包含按照一些额外的过滤条件进行排序等操作。在我们的代码中，因为参数是直接传递给数据连接层，所以我们可以直接使用ParameterObject模式来处理【注：ParameterObject就是把参数组装成对象】。

场景三：

使用@RequestParam绑定POJO

根据我的经验，很多开发没有替换较长的@RequestParams列表，主要还是因为他们不知道有什么替代的方案，因为在Spring的文档中没有提及。

下面，我们就开始来阐述替换的方案。首先我们可以使用一个POJO来包装这些参数。

@GetMapping
List<Product> searchProducts(ProductCriteria productCriteria) {
   return productRepository.search(productCriteria);
}
1
2
3
4

就已经完成了！

这个POJO本身没有要求额外的注解，但是POJO本身必须包含和请求参数完全匹配的字段，标准的setter/getter，和一个无参的构造器：

class ProductCriteria {
   private String query;
   private int offset;
   private int limit;
   ProductCriteria() {
   }
   public String getQuery() {
       return query;
   }
   public void setQuery(String query) {
       this.query = query;
   }
   // other getters/setters
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

在POJO中对请求参数进行校验

虽然上面的案例已经可以正常使用，但是我们知道，使用@RequestParam注解，不仅仅只是为了绑定请求参数，一个非常重要的功能是，我们可以对绑定的参数请求验证，比如参数是否必要，如果请求中缺少该参数，则我们的服务端可以拒绝该请求。

为了达到相同的功能，我们常常使用的替换方案是使用Java Bean Validation。java有很多内置的实现，我们也可以创建自己的bean验证器。

回到我们的POJO，我们想为我们的POJO中的字段添加验证规则。如果想模仿@RequestParam(required = false)的表现，我们可以使用@NotNull注解在对应的字段上即可。

在更多的情况下，我们一般使用@NotBlack多于@NotNull，因为@NotBlank考虑了空字符串的情况。

final class ProductCriteria {
   @NotBlank
   private String query;
   @Min(0)
   private int offset;
   @Min(1)
   private int limi;
   // ...
}
1
2
3
4
5
6
7
8
9

这里务必注意一点：

如果仅仅只是在对象的字段上添加验证注解是不够的。

一定要在controller的方法参数列表中，在POJO对应的参数前加上@Valid注解。该注解会让Spring在绑定参数前执行校验动作。

@GetMapping
List<Product> searchProducts(@Valid ProductCriteria productCriteria) {
   // ...
}
1
2
3
4

在POJO中设置请求参数的默认值

@RequestParam注解的另一个非常有用的功能就是设置参数的默认值。

如果我们使用POJO的方式来绑定参数，没有什么特别牛逼的方法，只需要在定义参数的时候设置好字段的默认值就行了。如果请求中没有该参数，Spring不会把参数的默认值覆盖为null的。

private int offset = 0;
private int limit = 10;
1
2

绑定多个参数对象

一般情况下，我们也不会强行把所有请求参数全部封装到一个对象中，我们可以把请求参数按照功能分布到多个POJO中。

为了验证这点，我们在查询方法中，添加一个排序的功能。首先，我们需要一个额外的对象，并添加一些校验约束：

final class SortCriteria {
   @NotNull
   private SortOrder order;
   @NotBlank
   private String sortAttribute;
   // constructor, getters/setters
}
1
2
3
4
5
6
7

在controller中，我们只需要把这个POJO作为另一个参数即可。但是仍然注意，想让校验生效，还是需要在参数对象前添加@Valid注解。

@GetMapping
List<Product> searchProducts(@Valid ProductCriteria productCriteria, @Valid SortCriteria sortCriteria) {
   // ...
}
1
2
3
4

内嵌对象

另一种处理请求参数对象的方式是使用组合。参数绑定对这种内嵌对象同样适用。

下面我们给出一个改进的例子，把查询对象移动到ProductCriteria中。

要让内置对象的字段能够执行验证，我们需要在内置对象对应的字段上添加@Valid注解。注意一点的是，如果这个内置对象的字段是null，Spring是不会校验这个属性的，这可以简单理解为，所有的内置对象属性都是可选的。如果想避免这种情况，在内置对象的字段上添加@NotNull注解。

final class ProductCriteria {
   @NotNull//注意这个@NotNull注解
   @Valid
   private SortCriteria sort;
   // ...
}
1
2
3
4
5
6

HTTP请求参数必须按照参数路径的方式命名。比如我们的例子中，请求参数就必须是：

sort.order=ASC&sort.attribute=name
1

不可变的DTO

现在，我们发现一个趋势，越来越多的开发会把传统的POJO中的setter方法去掉，让POJO变成一个不可变对象。

不可变对象有很多的好处，但是在我看来，最大的优势在于便于维护。

在你的开发中，是否有这样的情况，开着debug，在整个应用大量的代码中，去追踪一个对象的状态是怎么变化的？在什么地方，一个状态发生了什么样的变化？什么情况下，这个对象状态需要修改？对于很多对象来说，仅仅从setter方法的名字来看，是很难看出具体的业务逻辑的。

当Spring框架刚被创建出来的时候，是严格按照Java Bean规范来开发的。但是，时至今日，很多过去推崇的模式，已经变成了反模式。

要去掉setter方法，绑定请求参数，有两种方式，通过构造器或者字段直接绑定。但是目前没有一种非常简单的办法，直接通过构造方法将请求参数绑定，因为默认的构造方法是必须的。虽然我们可以把POJO的构造方法变为private的，并移除掉setter方法，从外部访问来看，确实变成了私有的，但是这种方式有一定的缺陷，比如内部组合对象无法使用这种方式。

默认情况下，Spring要求通过字段的setter方法来绑定参数，但是我们可以通过自定义的绑定器（binder）来直接把请求参数通过字段绑定。

为了可以在我们整个应用中，都使用这种绑定方式，那么你可以定义一个controller advice组件。通过@InitBinder 注解，来修改默认的绑定请求参数方法。

@ControllerAdvice
class BindingControllerAdvice {
   @InitBinder
   public void initBinder(WebDataBinder binder) {
       binder.initDirectFieldAccess();
   }
}
1
2
3
4
5
6
7

当我们创建好这个类之后，我们就可以把POJO中所有的setter方法去掉，让我们的POJO成为不可变对象。

final class ProductCriteria {
   @NotBlank
   private String query;
   @Min(0)
   private int offset = 0;
   @Min(1)
   private int limit = 10;
   private ProductCriteria() {
   }
   public String getQuery() {
       return query;
   }
   public int getOffset() {
       return offset;
   }
   public int getLimit() {
       return limit;
   }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

使用@RequestParam和不使用@RequestParam的区别

@RequestMapping("/list")
public String test(@RequestParam  Long parentId) {

}

@RequestMapping("/list")
public String test( Long parentId) {
            
}
1
2
3
4
5
6
7
8
9

第一种必须带有参数,也就是说你直接输入localhost:8080/list 会报错 不会执行方法 只能输入localhost:8080/list?parentId=? 才能执行相应的方法

第二种 可带参数也可不带参数 就是说你输入 localhost:8080/list 以及 localhost:8080/list?parentId=? 方法都能执行

当然你也可以设置 @RequestParam 里面的required为false(默认为true 代表必须带参数) 这样就跟第二种是一样的了

@RequestMapping("/list")
public String test(@RequestParam(required=false)  Long parentId) {
	.....
}
1
2
3
4

当然你还可以设置里面的defaultValue的属性

如下:

@RequestMapping("/list")
public String test(@RequestParam(defaultValue="0")  Long parentId) {
	...    
}
1
2
3
4

这样在地址里面也可以不带参数，如果带了参数会接收，不带参数会默认为0

里面还有一个value属性也讲一下， 前面所有的方法 传入的参数必须为parentId 才能接收到值

但是如果你加了value属性

@RequestMapping("/list")
public String test(@RequestParam(value="id")  Long parentId) {
    ..
}
1
2
3
4

这样会用id 代替parentId 也就是说你地址里面传入的参数名称为id localhost:8080/list?id＝？ 这种

RequestBody的使用

@RequestBody绑定一个对象实体

@PostMapping(value = "requestBody")
@ResponseBody
public User requestBody(@RequestBody  User user){
    System.out.println("user:"+user.getName());
    return user;
}
1
2
3
4
5
6

要求

1. 不支持get请求，因为get请求没有HttpEntity
2. 必须要在请求头中申明content-Type（如application/json）.springMvc通过HandlerAdapter配置的HttpMessageConverters解析httpEntity的数据，并绑定到相应的bean上
3. 只能一个@RequestBody。
4. 可以与@RequestParam一起使用，但建议最好不要与@RequestParam一起使用，是因为@RequestBody会将InputStream吃掉，造成后面的@RequsetParam无法匹配到参数而报400

如果后端参数是一个对象，且该参数前是以@RequestBody修饰的，那么前端传递json参数时，必须满足以下要求：

后端@RequestBody注解对应的类在将HTTP的输入流(含请求体)装配到目标类(也就是：@RequestBody后面的类)时，会根据json字符串中的key来匹配对应实体类的属性，如果匹配一致且json中的该key对应的值符合）(或者说：实体类的对应属性的类型要求时,会调用实体类的setter方法将值赋给该属性。)

1、json字符串中，如果value为 “” 的话（空串），后端对应属性如果是String类型的，那么接受到的就是 “” 如果是后端属性的类型是Integer、Double等类型，那么接收到的就是null。

2、json字符串中，如果value为null的话，后端对应收到的就是null。

3、如果某个参数没有value的话，在传json字符串给后端时，要么干脆就不把该字段写到json字符串中；要么写value时， 必须有值，null 或""都行。

千万不能有类似"stature":，这样的写法，如:

总结