REST(Representational State Transfer),译为:表现形式状态转换,它是一种软件架构风格
为什么要使用REST风格:
传统方式一般是一个请求url对应一种操作,这样做不仅麻烦,也不安全,因为会程序的人读取了你的 请求url地址,就大概知道该url实现的是一个什么样的操作。
查看REST风格的描述,你会发现请求地址变的简单了,并且光看请求URL并不是很能猜出来该URL的具体功能,
所以REST的优点有: 隐藏资源的访问行为,无法通过地址得知对资源是何种操作 书写简化
REST风格案例
REST按照不同的请求方式区分对资源进行何种操作
请求方式有很多种,常用的有四种,GET,POST,PUT,DELETE
按照案例上的请求方式对应相关操作
REST风格只是一种约定方式,不是规范,所以可以被打破,但是在开发的过程中,大部分人都是按照REST风格来开发,所以以后都是基于RESTFUL进行开发。
开发步骤:
1.保存
修改@RequestMapping参数
修改之前的增删改查,替换为RESTFUL的开发方式
之前不同的请求有不同的操作方式,现在将其修改为统一的请求路径
发送请求的方式要和method定义的操作相同
2.删除
修改@RequestMapping参数
删除方法需要携带所要删除数据的id,携带数据参数需要使用@PathVariable()
形参的名称和路径{}中的名称问题
形参名称id和路径user/{id)}相同,数据参数可以被传递
但下图的形参和注解中的参数不同,路径user/{id}对应了注解@PathVariable(id),前后参数只要一致,就能完成数据参数携带,形参的名称
多个参数需要传递书写问题
3.修改
4.查询
4.1根据ID查询
4.2查询所有
总结
@PathVariable
三个参数比较
@RequestParam用于接收url地址传参的普通参数, 集合类型参数
@RequestBody用于接收json数据,可以放在类上,或者方法上,方法里的形参定义上
@PathVariable用于接收路径参数,使用{参数名}来描述路径参数
后期开发中,发送请求参数超过一个时,以json为主,@RequestBody应用较广
发送非json数据,使用@RequestParam接收参数
优化RESTFUl入门案例
目前缺点:
每个方法上都有@RequestBody注解,重复性过高
每个方法的@RequestMapping都定义了相同的访问路径,重复性过高
每个方法的@RequestMapping都定义method属性请求方式,重复性过高
解决思路:
1.提取公因式
把方法上的@RequestBody提到类上,表示类中的所有方法都会有RequestBody的功能
使用@RestController注解替换@Controller与@ResponseBody注解,简化书写
把相同路径提取到类上,定义所有方法的共同路径
使用@GetMapping,@PostMapping,@PutMapping @DeleteMapping代替method方法
RESTFUl案例(带页面)
创建一个新的web的maven项目,项目结构如下,把网页静态资源复制到webapp目录下
在地址栏输入books.html的地址,SpringMVC会拦截静态资源
解决方法:
SpringMVC需要将静态资源进行放行。
新建一个配置类SpringMvcSupport
修改SpringMvcConfig文件,能够扫描到该配置类