前后端对接

一、 ResTful API 风格

HTTP方法

GET（SELECT）：从服务器取出资源（一项或多项）。

POST（CREATE）：在服务器新建一个资源。

PUT（UPDATE）：在服务器更新全部资源（客户端提供改变后的完整资源）。

PATCH（UPDATE）：在服务器更新部分资源（客户端提供改变的属性）。

DELETE（DELETE）：从服务器删除资源。

响应状态码

100~199：信息状态码，代表请求已被接受，需要继续处理。

200~299：成功状态码，代表请求已成功被服务器接收、理解、并接受。

300~399：重定向状态码，代表需要客户端采取进一步的操作才能完成请求。

400~499：客户端错误状态码，代表了客户端看起来可能发生了错误，妨碍了服务器的处理。

500~599：服务器错误状态码，代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。

特别注意几个常用的状态码：

200 请求已成功，请求所希望的响应头或数据体将随此响应返回。

400 1、语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。 　　

2、请求参数有误。

500 服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器的程序码出错时出现。

• 常见的文本、邮件、不能为空等，spring boot自带注解可以快速实现：@Valid注解和BindingResult验证请求参数的合法性并处理校验结果。（此块内容在开发中应用较为广泛，认真学习！）

例子：创建用户时，接口参数中用户名不能为空。@NotBlank(message = “用户名不能为空”)

提示：在请求方法的字段上加上@valid注解时，以上的注解将生效。如果请求接口的参数无法通过校验，将返回状态码为400（此处认真理解学习）

个人理解

常见注解：

正在上传…重新上传取消

自己使用，在后端使用Dto接收前端参数，在有要求的类上加上相应的注解，Controller层使用@valid注解接收参数使得Dto类中注解生效。

已经能够按照RestFulApi的方式返回400的错误信息，但是返回的异常信息不是很友好（有很多乱七八糟的字段，与我们自定义的400错误信息json结构不一致，那么前端接受到此json时还需特殊处理），并且错误信息也没有进行统一的维护。所以 我们重构注解的异常方法，让其错误信息按着我们统一格式返回。

三、默认的校验注解只能够满足一小部分校验要求。

例如需要校验一个字段是否唯一，就无法通过默认的注解完成。还有可能有更多的复杂校验逻辑，比如西仓项目需要校验一个询价单中所有的物料是否已经报价等（此处的开发很关键，每个项目都有大量这样的代码），常见的实现思路有二种，①重构校验注解（自定义注解）；②在service层【特别注意代码逻辑不允许写在controller层】代码逻辑判断后做异常抛出。

通过使用注解@ControllerAdvice，类RestExceptionHandler就可以实现全局异常的拦截处理功能。自定义的方handleResourceBadRequestException旨在拦截BadRequestException异常，一旦拦截成功后，我们可以进行各种处理操作，并且返回自己想要的结果。

在Service层可以进行逻辑处理，自己来控制抛出异常。

总结：使用此方式，代码精简、错误码与消息能够统一维护、返回客户端的状态更加明确，是符合RestFulApi的最佳实践。

四、 定义全局的异常处理方法，避免异常未经处理直接暴露给前端，前端无法处理未知错误的异常，经常给客户造成系统bug。     

特别注意----可以捕获到Controller层的异常，前提是Controller层没有对异常进行catch处理，如果Controller层对异常进行了catch处理，那么在这里就不会捕获到Controller层的异常了，所以这一点要特别注意（不是特殊业务需求，不用书写try catch）。

所有我们出异常后就转到自己定义好的ErrorController。

总结：如postman测试结果找不到此路由本来系统返回的是status 404状态，但通过重构全局的异常方法，将所有http错误状态统一返回status为500服务器内部错误状态（返回的status同样保留系统原始异常抛出的状态方便程序员定位错误原因），方便前端获取此状态后做统一的判断处理。避免由于系统开发造成的未知bug，引起前端做无状态的处理或者处理起来容易遗漏。

五、开发过程中需要注意如数据库密码、用户名等可配置信息请存放在配置文件中，读取配置文件参数，配置类在包config/DemoConfig.java（根据需求新增新的配置类）下面书写。配置文件 统一使用yml的方式，并且书写四个yml配置文件，用于不同环境下面的参数书写。

六、注解@JsonView的使用，有时候我们希望在不同的请求中隐藏一些字段。可以用@JsonView控制输出内容。

例子：条件查询时候不返回用户的密码，查看详情时候返回用户的密码。

我们使用@JsonView在要给前端返回的类中配合接口视图来控制字段的返回

七、使用前后端分离开发的项目，需要定义统一的前置路由规范

例子：http://localhost:8080/api/v1/user/1 api–代表后端接口，v1–代表版本

Yml中的实现：

server:

port: 8080

servlet:

context-path: “/api/v1”

八、代码逻辑必须写在service层，除非极为特殊情况，可以将少量逻辑放在controller。

九、SpringBoot Web项目的参数绑定：URL传参及默认参数设置

第一种情况：（参数类型必须书写包装类型），因为基本数据类型不能传null值，要传三个参数只传递两个相当于传递了null值。8个基本的数据类型如果在声明的时候没有初始化，编译器会赋予默认值，引用类型的对象（如String）默认值为null。但如果是局部变量（Local Variables，方法体内申明），编译器不会自动赋予初始值，会报编译错误。

第二种情况：

如果页面上表单里的参数和代码里的参数名不一样怎么办，这时候就可以用注解了：@RequestParam(value = “paramTest”)，自己起名把前端参数名和后端接收的参数名关联起来，如果传参名和Controller可以省略此注解。

第三种情况：

有时候页面上的表单客户不填任何值，但是在控制器里希望它有默认值

可以这样：@RequestParam(defaultValue = “5”)

第四种情况：

RequestParam还有个属性：required（必填）

但是当required=true，和defaultValue= 同时出现时，required失效，可传可不传

此处注意：需要拦截异常处理方法，让返回的错误码是我们的格式。

十、理解spring boot 自带tomcat

            org.springframework.boot

            spring-boot-starter-web

            

    

        

            org.springframework.boot

            spring-boot-starter-tomcat

        

    

之后可以自己导入tomcat相关依赖来启动项目