SpringBoot统一接口返回及全局异常处理高级用法

前言

现在大多数公司项目框架,基本都是属于前后端分离模式,这种模式会涉及到一个前后端对接问题,无论是对前端或者是后台服务,维护一套完善且规范的接口是非常有必要的,这样不仅能够提高对接效率,也可以让我的代码看起来更加简洁优雅。

修改前后最大的区别是我们不用在每个接口单独捕获异常,也不用在每个接口都要组装一遍返回参数,可以参考下面这张对比图:

一、SpringBoot不使用统一返回格式

默认情况下,SpringBoot会有如下三种返回情况。

1.1 使用字符串返回

@GetMapping("/getUserName")
public String getUserName(){
    return "HuaGe";
}

调用接口返回结果:

HuaGe

1.2 使用实体类返回

@GetMapping("/getUserName")
public User getUserName(){
    return new User("HuaGe",18,"男");
}

调用接口返回结果:

{
  "name": "HuaGe",
  "age": "18",
  "性别": "男",
}

1.3 异常情况下返回

@GetMapping("/getUserName")
public static String getUserName(){
    HashMap hashMap = Maps.newHashMap();
    return hashMap.get(0).toString();
}

模拟一个空指针异常,在不做任何异常处理的情况下,可以看下SpringBoot的默认返回结果:

{
    "timestamp": "2021-08-09T06:56:41.524+00:00",
    "status": 500,
    "error": "Internal Server Error",
    "path": "/sysUser/getUserName"
}

对于上面这几种情况,如果整个项目没有定义统一的返回格式,五个后台开发人员定义五种返回格式,这样不仅代码臃肿,前后端对接效率低,而且还会有一些意向不到的情况发生,比如前端直接显示异常详情等,这给用户的体验是非常差的。

二、基础玩法

项目中最常见到的是封装一个工具类,类中定义需要返回的字段信息,把需要返回前端的接口信息,通过该类进行封装,这样就可以解决返回格式不统一的现象了。

2.1 参数说明

  • code: 状态码,后台可以维护一套统一的状态码;
  • message: 描述信息,接口调用成功/失败的提示信息;
  • data: 返回数据。

2.2 流程说明

  • 新建Result类
public class Result<T> {

    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 <T> Result<T> success(T data) {
        Result<T> result = new Result<T>();
        result.setCode(ResultMsgEnum.SUCCESS.getCode());
        result.setMessage(ResultMsgEnum.SUCCESS.getMessage());
        result.setData(data);
        return result;
    }
​
    /**
     * 失败
     */
    public static <T> Result<T> 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(){
 &nbsp; &nbsp;return Result.success("huage");
}

调用结果如下,可以看到是我们在Result中定义的参数类型。

{
 &nbsp; &nbsp;"code": 0,
 &nbsp; &nbsp;"message": "成功",
 &nbsp; &nbsp;"data": "huage"
}

这样写虽然能够满足日常需求,而且我相信很多小伙伴也是这么用的,但是如果我们有大量的接口,然后在每一个接口中都使用Result.success来包装返回信息,会新增很多重复代码,显得不够优雅,甚至都不好意思拿出去显摆。 肯定会有一种方式能够再一次提高代码逼格,实现最优解。

三、进阶用法

基本用法学会后,接下来看点究极版本,主要用到如下两个知识点,用法简单,无论是拿出来教学妹,还是指点小姐姐,都是必备技能。

3.1 类介绍

  • ResponseBodyAdvice: 该接口是SpringMVC 4.1提供的,它允许在 执行 @ResponseBody后自定义返回数据,用来封装统一数据格式返回;
  • @RestControllerAdvice: 该注解是对Controller进行增强的,可以全局捕获抛出的异常。

3.2 用法说明

  • 新建ResponseAdvice类;
  • 实现ResponseBodyAdvice接口,实现supportsbeforeBodyWrite方法;
  • 该类用于统一封装controller中接口的返回结果。
@RestControllerAdvice
public class ResponseAdvice implements ResponseBodyAdvice<Object> {
    @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 {
 &nbsp; &nbsp;
}

如果我们有想要拦截的异常类型,就新增一个方法,使用@ExceptionHandler注解修饰,注解参数为目标异常类型。

例如:controller中接口发生Exception异常时,就会进入到Execption方法中进行捕获,将杂乱的异常信息,转换成指定格式后交给ResponseAdvice方法进行统一格式封装并返回给前端小伙伴。

@RestControllerAdvice
@Slf4j
public class CustomerExceptionHandler {
​
    @ExceptionHandler(AuthException.class)
    public String ErrorHandler(AuthorizationException e) {
        log.error("没有通过权限验证!", e);
        return "没有通过权限验证!";
    }
​
    @ExceptionHandler(Exception.class)
    public Result Execption(Exception e) {
        log.error("未知异常!", e);
        return Result.error(ResultMsgEnum.SERVER_BUSY.getCode(),ResultMsgEnum.SERVER_BUSY.getMessage());
    }
}

再次调用接口getUserName查看返回结果,会发现还是有一些问题,因为我们在CustomerExceptionHandler中已经将接口返回结果封装成Result类型,而代码执行到统一结果返回类ResponseAdvice时,又会结果再次封装,就出现了如下问题。

{
    "code": 0,
    "message": "成功",
    "data": {
        "code": 503,
        "message": "服务器正忙,请稍后再试!",
        "data": null
    }
}

3.4 统一返回结果处理类最终版

解决上述问题非常简单,只要在beforeBodyWrite中增加一条判断即可。

@RestControllerAdvice
public class ResponseAdvice implements ResponseBodyAdvice<Object> {
    @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();
            }
        }
        //返回类型是否已经封装
        if(o instanceof Result){
            return o;
        }
        return Result.success(o);
    }
}
​

至此,本章的任务就全部讲完,上述代码可以直接引用,不需要其他的配置项,非常推荐引用到自己的项目中。

四、总结

本章讲解的内容不是很多,主要就两个类的配置,即处理统一返回结果的类ResponseAdvice和异常处理类CustomerExceptionHandler。全文围绕RestControllerAdviceResponseBodyAdvice的使用,通过一步步的迭代,最终构建一套通用的代码代码返回格式,更多关于SpringBoot接口返回异常处理的资料请关注我们其它相关文章!

(0)

相关推荐

  • SpringBoot中如何进行统一异常处理

    目录 1.处理前 2.进行系统异常全局处理 3.进行自定义异常处理 总结 如何在SpringBoot项目里进行统一异常处理 需要了解的知识 @ControllerAdvice的作用 1.处理前 异常代码 /** * 根据id获取医院设置 * * @param id 查看的id编号 * @return */ @ApiOperation(value = "根据id获取医院设置") @GetMapping("/findHospById/{id}") public Resu

  • SpringBoot Security的自定义异常处理

    目录 SpringBoot Security自定义异常 access_denied 方面异常 Invalid access token 方面异常 Bad credentials 方面异常(登陆出错) 其他类 补充 SpringSecurity自定义响应异常信息 SpringBoot Security自定义异常 access_denied 方面异常 原异常 { "error": "access_denied", "error_description"

  • SpringBoot中如何统一接口返回与全局异常处理详解

    目录 背景 统一接口返回 定义API返回码枚举类 定义正常响应的API统一返回体 定义异常响应的API统一返回体 编写包装返回结果的自定义注解 定义返回结果拦截器 WebMvc配置类拦截器注册者添加返回结果拦截器 编写响应体处理器 接口调用 测试结果 全局异常处理 编写自定义异常基类 编写自定义业务异常类 定义全局异常处理类 接口调用 测试结果 总结 背景 在分布式.微服务盛行的今天,绝大部分项目都采用的微服务框架,前后端分离方式.前端和后端进行交互,前端按照约定请求URL路径,并传入相关参数,

  • springboot实现全局异常处理及自定义异常类

    目录 全局异常处理及自定义异常类 全局异常处理 定义一个业务异常的枚举 全局异常处理配置 springbootRestful使用 springboot返回ModelAndView 全局异常处理及自定义异常类 全局异常处理 定义一个处理类,使用@ControllerAdvice注解. @ControllerAdvice注解:控制器增强,一个被@Component注册的组件. 配合@ExceptionHandler来增强所有的@requestMapping方法. 例如:@ExceptionHandl

  • SpringBoot实现全局异常处理方法总结

    目录 全局异常处理 配置全局异常 全局异常处理的升级 加入自定义异常处理 处理Controller数据绑定.数据校验的异常 GlobalExceptionHandler全部代码 总结 在项目开发中出现异常时很平常不过的事情,我们处理异常也有很多种方式,可能如下: public int div(int a ,int b){ int c=0; try{ c=a/b; }catch (Exception ex){ ex.printStackTrace(); } return c; } 如果我们这样处理

  • SpringBoot中异常处理实战记录

    目录 一.背景 二.需求 三.编写一些异常基础代码 四.注意事项 五.总结 六.代码实现 七.参考文档 一.背景 在我们编写程序的过程中,程序中可能随时发生各种异常,那么我们如何优雅的处理各种异常呢? 二.需求 1.拦截系统中部分异常,返回自定义的响应. 比如: 系统发生HttpRequestMethodNotSupportedException异常,我们需要返回如下信息. http的状态码:返回 405 { code: 自定义异常码, message: 错误消息 } 2.实现自定义异常的拦截

  • SpringBoot全局异常处理方案分享

    目录 一 业务场景 二 全局系统异常类 一)全局系统异常类 二) 包装异常返回结果给前端,修改自定义异常 三 返回案例 一 业务场景 调用接口时需要对属性进行校验,比如属性长度,当属性为邮箱时校验邮箱格式等,这时候要要用到@Validated注解,在使用这个注解后发现出现了一个问题,调用接口后并没有返回我们想要的报错结果,而是返回了 "message": "Validation failed for object='IMMessageSend'. Error count: 1

  • SpringBoot统一接口返回及全局异常处理高级用法

    前言 现在大多数公司项目框架,基本都是属于前后端分离模式,这种模式会涉及到一个前后端对接问题,无论是对前端或者是后台服务,维护一套完善且规范的接口是非常有必要的,这样不仅能够提高对接效率,也可以让我的代码看起来更加简洁优雅. 修改前后最大的区别是我们不用在每个接口单独捕获异常,也不用在每个接口都要组装一遍返回参数,可以参考下面这张对比图: 一.SpringBoot不使用统一返回格式 默认情况下,SpringBoot会有如下三种返回情况. 1.1 使用字符串返回 @GetMapping("/get

  • Spring Boot统一接口返回及全局异常处理

    目录 1.解决方案 2.具体实现 2.1 定义状态码统一接口 2.2 公共模块状态码枚举类 2.3 定义全局自定义异常 2.4 定义统一接口格式输出类 2.5 定义统一接口格式输出类 2.6 接口统一输出优化 2.7 子系统如何实现 3.子系统定义状态码,实现BaseResultCode接口 前言: 前段时间接手了一个老项目,现在需要在此项目中添加一些新的需求,同事在开发过程中遇到了一些问题? 1.成功的状态到底是200还是0啊,订单系统200代表成功,而会员系统却是0代表成功. 2.接口返回的

  • springboot统一接口返回数据的实现

    一,没有异常的情况,正常返回数据 希望接口统一返回的数据格式如下: { "status": 0, "msg": "成功", "data": null } 和接口数据对应的bean /** * 统一返回结果的实体 * @param <T> */ public class Result<T> implements Serializable { private static final long serial

  • 关于springboot的接口返回值统一标准格式

    目录 一.目标 二.为什么要对springboot的接口返回值统一标准格式? 第一种格式:response为String 第二种格式:response为Objct 第三种格式:response为void 第四种格式:response为异常 三.定义response的标准格式 四.初级程序员对response代码封装 步骤1:把标准格式转换为代码 步骤2:把状态码存在枚举类里面 步骤3:加一个体验类 五.高级程序员对response代码封装 步骤1:采用ResponseBodyAdvice技术来实

  • 详解SpringBoot 统一后端返回格式的方法

    目录 为什么要对SpringBoot返回统一的标准格式 定义返回标准格式 定义返回对象 定义状态码 统一返回格式 高级实现方式 接口异常问题 SpringBoot为什么需要全局异常处理器 如何实现全局异常处理器 体验效果 全局异常接入返回的标准格式 首先我们来看看为什么要返回统一的标准格式? 为什么要对SpringBoot返回统一的标准格式 在默认情况下,SpringBoot的返回格式常见的有三种: 第一种:返回 String @GetMapping("/hello") public

  • SpringBoot 统一请求返回的实现

    目前我们的返回是直接把实体类扔给请求方,这样很不友好,一方面没有统一的格式,二来请求方不知道请求成功与否,没有一个可以判断的东西,也没有说明性的返回. 本篇就来为所有接口提供一个统一的友好返回. 确定返回结构 首先,我们先确定好我们接口返回的格式是什么样的,然后再一步一步实现下面的. { "code": 200, "msg": "ok", "data": "" } code 字段表示状态码,调用方根据该码来

  • SpringBoot统一api返回风格的实现

    学过上一章的人也许发现问题了,接口返回的格式基本都是固定的,例如 { "code": 200, "msg": "", "data": "Object ....", } 而我们的登陆却返回 密码必须传!等等返回值 显然我们的返回格式不符合常规开发,因为前台并不知道这是错误信息还是正确返回信息! 所以我们简单封装一个返回类,代码如下 添加base包,新建BaseResult类 import lombok.Dat

  • SpringBoot 统一公共返回类的实现

    目录 项目结构 统一返回类使用 本文记录下如何在工程中,配置后台的统一公共返回类,这样做目的是为了统一返回信息,方便项目进行管理.使用技术:SpringBoot+Swagger+Lombok 项目结构 具体过程如下,在response文件夹下分别建立 CustomizeResultCode 接口,枚举类ResultCode 实现CustomizeResultCode 接口和Result类: 1 配置自定义返回类接口,该接口中包含 错误状态码和错误信息 public interface Custo

  • .NetCore Web Api 利用ActionFilterAttribute统一接口返回值格式及问题解析

    .Net Core 同 Asp.Net MVC一样有几种过滤器,这里不再赘述每个过滤器的执行顺序与作用. 在实际项目开发过程中,统一API返回值格式对前端或第三方调用将是非常必要的,在.NetCore中我们可以通过ActionFilterAttribute来进行统一返回值的封装. 在封装之前我们需要考虑下面几个问题: 1,需要对哪些结果进行封装 我目前的做法是,只对ObjectResult进行封装,其他的类型:FileResult,ContentResult,EmptyResult,Redire

随机推荐