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文件，能够扫描到该配置类
