本次面试答案,以及收集到的大厂必问面试题分享:
“error”: “Internal Server Error”,
“path”: “/sysUser/getUserName”
}
对于上面这几种情况,如果整个项目没有定义统一的返回格式,五个后台开发人员定义五种返回格式,这样不仅代码臃肿,前后端对接效率低,而且还会有一些意向不到的情况发生,比如前端直接显示异常详情等,这给用户的体验是非常差的。
二、基础玩法
======
项目中最常见到的是封装一个工具类,类中定义需要返回的字段信息,把需要返回前端的接口信息,通过该类进行封装,这样就可以解决返回格式不统一的现象了。
2.1 参数说明
========
-
code: 状态码,后台可以维护一套统一的状态码;
-
message: 描述信息,接口调用成功/失败的提示信息;
-
data: 返回数据。
2.2 流程说明
========
- 新建Result类
public class Result {
private int code;
private String message;
private T data;
public Result() {}
public Result(int code, String message) {
this.code = code;
this.message = message;
}
/**
- 成功
*/
public static Result success(T data) {
Result result = new Result();
result.setCode(ResultMsgEnum.SUCCESS.getCode());
result.setMessage(ResultMsgEnum.SUCCESS.getMessage());
result.setData(data);
return result;
}
/**
- 失败
*/
public static Result error(int code, String message) {
return new Result(code, message);
}
}
- 定义返回状态码
public enum ResultMsgEnum {
SUCCESS(0, “成功”),
FAIL(-1, “失败”),
AUTH_ERROR(502, “授权失败!”),
SERVER_BUSY(503, “服务器正忙,请稍后再试!”),
DATABASE_OPERATION_FAILED(504, “数据库操作失败”);
private int code;
private String message;
ResultMsgEnum(int code, String message) {
this.code = code;
this.message = message;
}
public int getCode() {
return this.code;
}
public String getMessage() {
return this.message;
}
}
- 使用方式
上面两步定义了数据返回格式和状态码,接下来就要看下在接口中如何使用了。
@GetMapping(“/getUserName”)
public Result getUserName(){
return Result.success(“huage”);
}
调用结果如下,可以看到是我们在Result中定义的参数类型。
{
“code”: 0,
“message”: “成功”,
“data”: “huage”
}
这样写虽然能够满足日常需求,而且我相信很多小伙伴也是这么用的,但是如果我们有大量的接口,然后在每一个接口中都使用Result.success来包装返回信息,会新增很多重复代码,显得不够优雅,甚至都不好意思拿出去显摆。 肯定会有一种方式能够再一次提高代码逼格,实现最优解。
三、进阶用法
======
基本用法学会后,接下来看点究极版本,主要用到如下两个知识点,用法简单,无论是拿出来教学妹,还是指点小姐姐,都是必备技能。
3.1 类介绍
=======
3.1类介绍
======
3.1 类介绍
=======
-
ResponseBodyAdvice: 该接口是SpringMVC 4.1提供的,它允许在 执行 @ResponseBody后自定义返回数据,用来封装统一数据格式返回;
-
@RestControllerAdvice: 该注解是对Controller进行增强的,可以全局捕获抛出的异常。
3.2 用法说明
========
-
新建ResponseAdvice类;
-
实现ResponseBodyAdvice接口,实现supports、beforeBodyWrite方法;
-
该类用于统一封装controller中接口的返回结果。
@RestControllerAdvice
public class ResponseAdvice implements ResponseBodyAdvice {
@Autowired
private ObjectMapper objectMapper;
/**
- 是否开启功能 true:是
*/
@Override
public boolean supports(MethodParameter methodParameter, Class<? extends HttpMessageConverter<?>> aClass) {
return true;
}
/**
- 处理返回结果
*/
@Override
public Object beforeBodyWrite(Object o, MethodParameter methodParameter, MediaType mediaType, Class<? extends HttpMessageConverter<?>> aClass, ServerHttpRequest serverHttpRequest, ServerHttpResponse serverHttpResponse) {
//处理字符串类型数据
if(o instanceof String){
try {
return objectMapper.writeValueAsString(Result.success(o));
} catch (JsonProcessingException e) {
e.printStackTrace();
}
}
return Result.success(o);
}
}
我们可以通过getUserName接口测试一下,会发现和直接使用Result返回的结果是一致的。
不过,细心的小伙伴们肯定注意到了,在ResponseAdvice我们全部使用了Result.success(o)来处理结果,对于error类型的结果未做处理。我们来看下,发生异常情况时,返回结果是什么样呢?继续使用上面HashMap空指针异常的代码,测试结果如下:
{
“code”: 0,
“message”: “成功”,
“data”: {
“timestamp”: “2021-08-09T09:33:26.805+00:00”,
“status”: 405,
“error”: “Method Not Allowed”,
“path”: “/sysUser/getUserName”
}
}
虽然格式上没有毛病,但是在code、data字段的具体数据上是不友好或不正确的。不处理好这些事情,会严重影响自己在前端妹妹心中的高大形象的,这是决不能容忍的。
3.3 全局异常处理器
===========
以前我们遇到异常时,第一时间想到的应该是try…catch…finnal吧,不过这种方式会导致大量代码重复,维护困难,逻辑臃肿等问题,这不是我们想要的结果。
今天我们要用的全局异常处理方式,用起来是比较简单的。首先新增一个类,增加@RestControllerAdvice注解,该注解的作用花哥上面已经介绍过,就不再唠叨了。
@RestControllerAdvice
public class CustomerExceptionHandler {
}
如果我们有想要拦截的异常类型,就新增一个方法,使用@ExceptionHandler注解修饰,注解参数为目标异常类型。
例如:controller中接口发生Exception异常时,就会进入到Execption方法中进行捕获,将杂乱的异常信息,转换成指定格式后交给ResponseAdvice方法进行统一格式封装并返回给前端小伙伴。
@RestControllerAdvice
@Slf4j
public class CustomerExceptionHandler {
最后
按照上面的过程,4个月的时间刚刚好。当然Java的体系是很庞大的,还有很多更高级的技能需要掌握,但不要着急,这些完全可以放到以后工作中边用别学。
学习编程就是一个由混沌到有序的过程,所以你在学习过程中,如果一时碰到理解不了的知识点,大可不必沮丧,更不要气馁,这都是正常的不能再正常的事情了,不过是“人同此心,心同此理”的暂时而已。
“道路是曲折的,前途是光明的!”
以后工作中边用别学。
学习编程就是一个由混沌到有序的过程,所以你在学习过程中,如果一时碰到理解不了的知识点,大可不必沮丧,更不要气馁,这都是正常的不能再正常的事情了,不过是“人同此心,心同此理”的暂时而已。
“道路是曲折的,前途是光明的!”
[外链图片转存中…(img-hOa9Z9aD-1715244761954)]
[外链图片转存中…(img-Jx9dOrzK-1715244761954)]