目录
- 请求与响应
- 请求参数
- 参数传递
- 五种类型参数传递
- 普通参数
- POJO数据类型
- 嵌套POJO类型参数
- 数组类型参数
- 集合类型参数
- JSON数据传输参数
- JSON对象数据
- JSON对象数组
- 响应
- 返回文本数据[了解]
- 响应JSON数据
- REST风格
- REST简介
- RESTful入门案例
- RESTful快速开发
请求与响应
请求参数
参数传递
- GET发送单个参数
发送请求与参数:
接收参数:
- GET发送多个参数
发送请求与参数:
接收参数:
GET请求中文乱码
如果我们传递的参数中有中文,你会发现接收到的参数会出现中文乱码问题。
发送请求: http://localhost/commonParam?name=张三&age=18
控制台:
出现乱码的原因相信大家都清楚,Tomcat8.5以后的版本已经处理了中文乱码的问题,但是IDEA中的Tomcat插件目前只到Tomcat7,所以需要修改pom.xml来解决GET请求中文乱码问题
<build>
<plugins>
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.1</version>
<configuration>
<port>80</port><!--tomcat端口号-->
<path>/</path> <!--虚拟目录-->
<uriEncoding>UTF-8</uriEncoding><!--访问路径编解码字符集-->
</configuration>
</plugin>
</plugins>
</build>
- POST发送参数
发送请求与参数:
接收参数:
和GET一致,不用做任何修改
POST请求中文乱码
发送请求与参数:
接收参数:
控制台打印,会发现有中文乱码问题。
解决方案:配置过滤器
CharacterEncodingFilter是在spring-web包中,所以用之前需要导入对应的jar包。
五种类型参数传递
普通参数
普通参数:url地址传参,地址参数名与形参变量名相同,定义形参即可接收参数。
如果形参与地址参数名不一致该如何解决?
发送请求与参数:
后台接收参数:
因为前端给的是name ,后台接收使用的是userName ,两个名称对不上,导致接收数据失败:
解决方案:使用@RequestParam注解
注意:写上@RequestParam注解框架就不需要自己去解析注入,能提升框架处理性能
POJO数据类型
简单数据类型一般处理的是参数个数比较少的请求,如果参数比较多,那么后台接收参数的时候就比较复杂,这个时候我们可以考虑使用POJO数据类型。
POJO参数:请求参数名与形参对象属性名相同,定义POJO类型形参即可接收参数
此时需要使用前面准备好的POJO类,先来看下User
发送请求和参数:
后台接收参数:
注意:
- POJO参数接收,前端GET和POST发送请求数据的方式不变。
- 请求参数key的名称要和POJO中属性的名称一致,否则无法封装。
嵌套POJO类型参数
如果POJO对象中嵌套了其他的POJO类,如
嵌套POJO参数:请求参数名与形参对象属性名相同,按照对象层次结构关系即可接收嵌套POJO属性参数
发送请求和参数:
后台接收参数:
注意:
请求参数key的名称要和POJO中属性的名称一致,否则无法封装
数组类型参数
举个简单的例子,如果前端需要获取用户的爱好,爱好绝大多数情况下都是多个,如何发送请求数据和接收数据呢?
数组参数:请求参数名与形参对象属性名相同且请求参数为多个,定义数组类型即可接收参数
发送请求和参数:
后台接收参数:
集合类型参数
数组能接收多个值,那么集合是否也可以实现这个功能呢?
发送请求和参数:
后台接收参数:
运行会报错,
错误的原因是:SpringMVC将List看做是一个POJO对象来处理,将其创建一个对象并准备把前端的数据封装到对象中,但是List是一个接口无法创建对象,所以报错。
解决方案是:使用@RequestParam注解
- 集合保存普通参数:请求参数名与形参集合对象名相同且请求参数为多个,@RequestParam绑定参数关系
- 对于简单数据类型使用数组会比集合更简单些。
知识点1:@RequestParam
JSON数据传输参数
前面我们说过,现在比较流行的开发方式为异步调用。前后台以异步方式进行交换,传输的数据使用的是JSON,所以前端如果发送的是JSON数据,后端该如何接收?
对于JSON数据类型,我们常见的有三种:
- json普通数组([“value1”,“value2”,“value3”,…])
- json对象({key1:value1,key2:value2,…})
- json对象数组([{key1:value1,…},{key2:value2,…}])
对于上述数据,前端如何发送,后端如何接收?
- JSON普通数组
步骤1:pom.xml添加依赖
SpringMVC默认使用的是jackson来处理json的转换,所以需要在pom.xml添加jackson依赖
步骤2:PostMan发送JSON数据
步骤3:开启SpringMVC注解支持
在SpringMVC的配置类中开启SpringMVC的注解支持,这里面就包含了将JSON转换成对象的功能。
步骤4:参数前添加@RequestBody
步骤5:启动运行程序
JSON普通数组的数据就已经传递完成,下面针对JSON对象数据和JSON对象数组的数据该如何传递呢?
JSON对象数据
我们会发现,只需要关注请求和数据如何发送?后端数据如何接收?
请求和数据的发送:
后端接收数据:
启动程序访问测试
说明:
address为null的原因是前端没有传递数据给后端。
如果想要address也有数据,我们需求修改前端传递的数据内容:
再次发送请求,就能看到address中的数据
JSON对象数组
集合中保存多个POJO该如何实现?
请求和数据的发送:
后端接收数据:
启动程序访问测试
小结
SpringMVC接收JSON数据的实现步骤为:
(1)导入jackson包
(2)使用PostMan发送JSON数据
(3)开启SpringMVC注解驱动,在配置类上添加@EnableWebMvc注解
(4)Controller方法的参数前添加@RequestBody注解
知识点1:@EnableWebMvc
知识点2:@RequestBody
@RequestBody与@RequestParam区别
- 区别
- @RequestParam用于接收url地址传参,表单传参【application/x-www-form-urlencoded】
- @RequestBody用于接收json数据【application/json】
- 应用
- 后期开发中,发送json格式数据为主,@RequestBody应用较广
- 如果发送非json格式数据,选用@RequestParam接收请求参数
响应
返回文本数据[了解]
还不能称作返回json数据,这只是返回字符串。
响应JSON数据
响应POJO对象
返回值为实体类对象,设置返回值为实体类类型,即可实现返回对应对象的json数据,需要依赖
@ResponseBody注解和@EnableWebMvc注解
知识点1:@ResponseBody
说明:
- 该注解可以写在类上或者方法上
- 写在类上就是该类下的所有方法都有@ReponseBody功能
- 当方法上有@ReponseBody注解后
- 方法的返回值为字符串,会将其作为文本内容直接响应给前端
- 方法的返回值为对象,会将对象转换成JSON响应给前端
此处又使用到了类型转换,内部还是通过Converter接口的实现类完成的,所以Converter除了前面所说的功能外,它还可以实现:
- 对象转Json数据(POJO -> json)
- 集合转Json数据(Collection -> json)
REST风格
REST简介
REST(Representational State Transfer),表现形式状态转换,它是一种软件架构风格。
当我们想表示一个网络资源的时候,可以使用两种方式:
- 传统风格资源描述形式
- http://localhost/user/getById?id=1查询id为1的用户信息
- http://localhost/user/saveUser保存用户信息
- REST风格描述形式
http://localhost/user/1
http://localhost/user
传统方式一般是一个请求url对应一种操作,这样做不仅麻烦,也不安全,因为会程序的人读取了你的请求url地址,就大概知道该url实现的是一个什么样的操作。
查看REST风格的描述,你会发现请求地址变的简单了,并且光看请求URL并不是很能猜出来该URL的具体功能
所以REST的优点有: - 隐藏资源的访问行为,无法通过地址得知对资源是何种操作
- 书写简化
但是我们的问题也随之而来了,一个相同的url地址即可以是新增也可以是修改或者查询,那么到底我们该如何区分该请求到底是什么操作呢? - 按照REST风格访问资源时使用行为动作区分对资源进行了何种操作
请求的方式比较多,但是比较常用的就4种,分别是GET , POST , PUT , DELETE。
按照不同的请求方式代表不同的操作类型。 - 发送GET请求是用来做查询
- 发送POST请求是用来做新增
- 发送PUT请求是用来做修改
- 发送DELETE请求是用来做删除
但是注意: - 上述行为是约定方式,约定不是规范,可以打破,所以称REST风格,而不是REST规范
- REST提供了对应的架构方式,按照这种架构设计项目可以降低开发的复杂性,提高系统的可伸缩性
- REST中规定GET/POST/PUT/DELETE针对的是查询/新增/修改/删除,但是我们如果非要用GET请求做删除,这点在程序上运行是可以实现的
- 但是如果绝大多数人都遵循这种风格,你写的代码让别人读起来就有点莫名其妙了。
- 描述模块的名称通常使用复数,也就是加s的格式描述,表示此类资源,而非单个资源,例如:users、books、accounts…
清楚了什么是REST风格后,我们后期会经常提到一个概念叫RESTful,那什么又是RESTful呢? - 根据REST风格对资源进行访问称为RESTful。
后期我们在进行开发的过程中,大多是都是遵从REST风格来访问我们的后台服务,所以可以说咱们以后都是基于RESTful来进行开发的。
RESTful入门案例
@GetMapping(path = "/public/ratio/page")
public HttpResponseBean<PageBean<RatioResponse>> ratioPage(RatioRequest ratioRequest) {
PageBean<RatioResponse> pageInfo = ratioService.getRatioPage(ratioRequest);
return HttpResponseBean.ok(pageInfo);
}
@PostMapping(path = "/public/proportionalResolution")
public HttpResponseBean<List<ProportionalResolution>> proportionalResolution(@RequestBody RatioRequest ratioRequest) {
List<ProportionalResolution> proportionalResolutionResponse = proportionalResolutionService.findProportionalResolutionByRatio(ratioRequest);
return HttpResponseBean.ok(proportionalResolutionResponse);
}
RESTful快速开发
- @Controller + @ResponseBody合并为@RestController放在类上
- @RequestMapping(value=“/books”,method=RequestMethod.POST),每个方法上都有value=“/books”,抽取@RequestMapping(“/books”)放在类上,这时每个方法上变为@RequestMapping(value = “/books”,method=RequestMethod.POST),等价为@PostMapping(“/books”)