年轻人不讲武德，竟然重构出这么优雅后台API接口

 本文转载自微信公众号「Java极客技术」，作者鸭血粉丝 。转载本文请联系Java极客技术公众号。   

 Hello，早上好，我是阿粉~

最近偶然间在看到 Spring 官方文档的时候，新学到一个注解 @ControllerAdvice，并且成功使用这个注解重构我们项目的对外 API 接口，去除繁琐的重复代码，使其开发更加优雅。

展示具体重构代码之前，我们先来看下原先对外 API 接口是如何开发的。

这个 API 接口主要是用来与我们 APP 交互，这个过程我们统一定义一个交互协议，APP 端与后台 API 接口统一都使用 JSON 格式。

另外后台 API 接口对 APP 返回时，统一一些错误码，APP 端需要根据相应错误码，在页面弹出一些提示。

下面展示一个查询用户信息返回的接口数据：

 
 
 
    
  
  
  
  1. { 
    2. 
  
  
  
  2.     "code": "000000", 
    3. 
  
  
  
  3.     "msg": "success", 
    4. 
  
  
  
  4.     "result": { 
    5. 
  
  
  
  5.         "id": "1", 
    6. 
  
  
  
  6.         "name": "test" 
    7. 
  
  
  
  7.     } 
    8. 
  
  
  
  8. } 
    9.

code代表对外的错误码，msg代表错误信息，result代表具体返回信息。

前端 APP 获取这个返回信息，首先判断接口返回 code是否为 「000000」，如果是代表查询成功，然后获取 result 信息作出相应的展示。否则，直接弹出相应的错误信息。

重构之前

下面我们来看下，重构之前的，后台 API 层的如何编码。

 
 
 
    
  
  
  
  1. /** 
    2. 
  
  
  
  2.  * V1 版本 
    3. 
  
  
  
  3.  * 
    4. 
  
  
  
  4.  * @return 
    5. 
  
  
  
  5.  */ 
    6. 
  
  
  
  6. @RequestMapping("testv1") 
    7. 
  
  
  
  7. public APIResult testv1() { 
    8. 
  
  
  
  8.     try { 
    9. 
  
  
  
  9.         User user = new User(); 
    10. 
  
  
  
  10.         user.setId("1"); 
    11. 
  
  
  
  11.         user.setName("test"); 
    12. 
  
  
  
  12.         return APIResult.success(user); 
    13. 
  
  
  
  13.     } catch (APPException e) { 
    14. 
  
  
  
  14.         log.error("内部异常", e); 
    15. 
  
  
  
  15.         return APIResult.error(e.getCode(), e.getMsg()); 
    16. 
  
  
  
  16.     } catch (Exception e) { 
    17. 
  
  
  
  17.         log.error("系统异常", e); 
    18. 
  
  
  
  18.         return APIResult.error(RetCodeEnum.FAILED); 
    19. 
  
  
  
  19.     } 
    20. 
  
  
  
  20. } 
    21.

上面的代码其实很简单，内部统一封装了一个工具类 APIResult，然后用其包装具体的结果。

 
 
 
    
  
  
  
  1. @Data 
    2. 
  
  
  
  2. public class APIResult implements Serializable { 
    3. 
  
  
  
  3.  
    4. 
  
  
  
  4.     private static final long serialVersionUID = 4747774542107711845L; 
    5. 
  
  
  
  5.  
    6. 
  
  
  
  6.     private String code; 
    7. 
  
  
  
  7.  
    8. 
  
  
  
  8.     private String msg; 
    9. 
  
  
  
  9.  
    10. 
  
  
  
  10.     private T result; 
    11. 
  
  
  
  11.  
    12. 
  
  
  
  12.  
    13. 
  
  
  
  13.     public static  APIResult success(T result) { 
    14. 
  
  
  
  14.         APIResult apiResult = new APIResult(); 
    15. 
  
  
  
  15.         apiResult.setResult(result); 
    16. 
  
  
  
  16.         apiResult.setCode("000000"); 
    17. 
  
  
  
  17.         apiResult.setMsg("success"); 
    18. 
  
  
  
  18.         return apiResult; 
    19. 
  
  
  
  19.     } 
    20. 
  
  
  
  20.  
    21. 
  
  
  
  21.     public static APIResult error(String code, String msg) { 
    22. 
  
  
  
  22.         APIResult apiResult = new APIResult(); 
    23. 
  
  
  
  23.         apiResult.setCode(code); 
    24. 
  
  
  
  24.         apiResult.setMsg(msg); 
    25. 
  
  
  
  25.         return apiResult; 
    26. 
  
  
  
  26.     } 
    27. 
  
  
  
  27.  
    28. 
  
  
  
  28.     public static APIResult error(RetCodeEnum codeEnum) { 
    29. 
  
  
  
  29.         APIResult apiResult = new APIResult(); 
    30. 
  
  
  
  30.         apiResult.setCode(codeEnum.getCode()); 
    31. 
  
  
  
  31.         apiResult.setMsg(codeEnum.getMsg()); 
    32. 
  
  
  
  32.         return apiResult; 
    33. 
  
  
  
  33.     } 
    34.

除了这个以外，还定义一个异常对象 APPException，用来统一包装内部的各种异常。

上面的代码很简单，但是呢可以说比较繁琐，重复代码也比较多，每个接口都需要使用 try...catch 包装，然后使用 APIResult包括正常的返回信息与错误信息。

第二呢，接口对象只能返回 APIResult，真实业务对象只能隐藏在 APIResult中。这样不太优雅，另外不能很直观知道真实业务对象。

重构之后

下面我们开始重构上面的代码，主要目的是去除重复的那一坨try...catch 代码。

这次重构我们需要使用Spring 注解 @ControllerAdvice以及 ResponseBodyAdvice，我们先来看下重构的代码。

ps: ResponseBodyAdvice来自 Spring 4.2 API，如果各位同学需要使用这个的话，可能需要升级 Spring 版本。

改写返回信息

首先我们需要实现 ResponseBodyAdvice，实现我们自己的处理类。

 
 
 
    
  
  
  
  1. @ControllerAdvice 
    2. 
  
  
  
  2. public class CustomResponseAdvice implements ResponseBodyAdvice { 
    3. 
  
  
  
  3.     /** 
    4. 
  
  
  
  4.      * 是否需要处理返回结果 
    5. 
  
  
  
  5.      * @param methodParameter 
    6. 
  
  
  
  6.      * @param aClass 
    7. 
  
  
  
  7.      * @return 
    8. 
  
  
  
  8.      */ 
    9. 
  
  
  
  9.     @Override 
    10. 
  
  
  
  10.     public boolean supports(MethodParameter methodParameter, Class aClass) { 
    11. 
  
  
  
  11.         System.out.println("In supports() method of " + getClass().getSimpleName()); 
    12. 
  
  
  
  12.         return true; 
    13. 
  
  
  
  13.     } 
    14. 
  
  
  
  14.  
    15. 
  
  
  
  15.     /** 
    16. 
  
  
  
  16.      * 处理返回结果 
    17. 
  
  
  
  17.      * @param body 
    18. 
  
  
  
  18.      * @param methodParameter 
    19. 
  
  
  
  19.      * @param mediaType 
    20. 
  
  
  
  20.      * @param aClass 
    21. 
  
  
  
  21.      * @param serverHttpRequest 
    22. 
  
  
  
  22.      * @param serverHttpResponse 
    23. 
  
  
  
  23.      * @return 
    24. 
  
  
  
  24.      */ 
    25. 
  
  
  
  25.     @Override 
    26. 
  
  
  
  26.     public Object beforeBodyWrite(Object body, MethodParameter methodParameter, MediaType mediaType, Class aClass, ServerHttpRequest serverHttpRequest, ServerHttpResponse serverHttpResponse) { 
    27. 
  
  
  
  27.         System.out.println("In beforeBodyWrite() method of " + getClass().getSimpleName()); 
    28. 
  
  
  
  28.         if (body instanceof APIResult) { 
    29. 
  
  
  
  29.             return body; 
    30. 
  
  
  
  30.         } 
    31. 
  
  
  
  31.         return APIResult.success(body); 
    32. 
  
  
  
  32.     } 
    33. 
  
  
  
  33. } 
    34.

实现上面的接口，我们就可以在 beforeBodyWrite方法里，修改返回结果了。

上面代码中，只是简单使用 APIResult包装了返回结果，然后返回。其实我们还可以在此增加一些额外逻辑，比如说如接口返回信息由加密的需求，我们可以在这一层统一加密。

另外，这里判断一下 body 是否 APIResult类，如果是就直接返回，不做修改。

这么做一来兼容之前的老接口，这是因为默认情况下，我们自己实现的 CustomResponseAdvice类，将会对所有的 Controller 生效。

如果不做判断，以前的老接返回就会被包装了两层 APIResul,影响 APP 解析。

除此之外，如果大家担心这个修改对以前的老接口有影响的话，可以使用下面的方式，只对指定的方法生效。

首先自定义一个注解，比如说：

 
 
 
    
  
  
  
  1. @Target({ElementType.TYPE, ElementType.METHOD}) 
    2. 
  
  
  
  2. @Retention(RetentionPolicy.RUNTIME) 
    3. 
  
  
  
  3. @Documented 
    4. 
  
  
  
  4. public @interface CustomResponse { 
    5. 
  
  
  
  5. } 
    6.

然后将其标注在需要改动的方法中，然后我们在 ResponseBodyAdvice#supports中判断具体方法上有没有自定义注解 CustomResponse，如果存在，返回 true，这就代表最后将会修改返回类。如果不存在，则返回 false，那么就会跟以前流程一样。

 
 
 
    
  
  
  
  1. /** 
    2. 
  
  
  
  2.  * 是否需要处理返回结果 
    3. 
  
  
  
  3.  * 
    4. 
  
  
  
  4.  * @param methodParameter 
    5. 
  
  
  
  5.  * @param aClass 
    6. 
  
  
  
  6.  * @return 
    7. 
  
  
  
  7.  */ 
    8. 
  
  
  
  8. @Override 
    9. 
  
  
  
  9. public boolean supports(MethodParameter methodParameter, Class aClass) { 
    10. 
  
  
  
  10.     System.out.println("In supports() method of " + getClass().getSimpleName()); 
    11. 
  
  
  
  11.     Method method = methodParameter.getMethod(); 
    12. 
  
  
  
  12.     return method.isAnnotationPresent(CustomResponse.class); 
    13. 
  
  
  
  13. } 
    14.

全局异常处理

上面的代码重构之后，将重复代码抽取了出来，整体的代码就剩下我们的业务逻辑，这样就变得非常简洁优雅。

不过，上面的重构的代码，还是存在问题，主要是异常的处理。

如果上面的业务代码抛出了异常，那么接口将会返回堆栈错误信息，而不是我们定义的错误信息。所以下面我们这个，再次优化一下。

这次我们主要需要使用 @ExceptionHandler注解，这个注解需要与 @ControllerAdvice 一起使用。

 
 
 
    
  
  
  
  1. @Slf4j 
    2. 
  
  
  
  2. @ControllerAdvice 
    3. 
  
  
  
  3. public class CustomExceptionHandler { 
    4. 
  
  
  
  4.  
    5. 
  
  
  
  5.     @ExceptionHandler(Exception.class) 
    6. 
  
  
  
  6.     @ResponseBody 
    7. 
  
  
  
  7.     public APIResult handleException(Exception e) { 
    8. 
  
  
  
  8.         log.error("系统异常", e); 
    9. 
  
  
  
  9.         return APIResult.error(RetCodeEnum.FAILED); 
    10. 
  
  
  
  10.     } 
    11. 
  
  
  
  11.  
    12. 
  
  
  
  12.     @ExceptionHandler(APPException.class) 
    13. 
  
  
  
  13.     @ResponseBody 
    14. 
  
  
  
  14.     public APIResult handleAPPException(APPException e) { 
    15. 
  
  
  
  15.         log.error("内部异常", e); 
    16. 
  
  
  
  16.         return APIResult.error(e.getCode(), e.getMsg()); 
    17. 
  
  
  
  17.     } 
    18. 
  
  
  
  18.  
    19. 
  
  
  
  19. } 
    20.

使用这个 @ExceptionHandler，将会拦截相应的异常，然后将会调用的相应方法处理异常。这里我们就使用 APIResult包装一些错误信息返回。

总结

我们可以使用 @ControllerAdvice加 ResponseBodyAdvice 拦截返回结果，统一做出一些修改。这样就可以使用的业务代码非常简洁，优雅。

另外，针对业务代码的中，我们可以使用 @ExceptionHandler注解，统一做一个全局异常处理，这样就可以无缝的跟 ResponseBodyAdvice结合。

不过这里需要一点，我们实现的 ResponseBodyAdvice 类，一定需要跟 @ControllerAdvice配合一起使用哦，至于具体原因，下篇文章阿粉分析原来的时候，再具体解释哦。敬请期待哦~

分享文章：年轻人不讲武德，竟然重构出这么优雅后台API接口
标题网址：http://www.shufengxianlan.com/qtweb/news20/445420.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

云服务器知识

同城分类信息

成都二枢机房　　 　攀枝花网站建设　　 　成都联通服务器托管　　 　网站建设公司　　 　成都小程序　　 　乐山网站建设　　 　兴发搬家　　 　网站seo优化　　 　手机软件开发　　 　成都做网站　　 　分类目录网站　　 　四川成都展柜定制厂家　　 　雅安托管服务器　　 　成都棕树电信机房　　 　德阳服务器托管　　 　营销型网站建设　　 　网站运维托管　　 　网站空间　　 　成都商城网站建设　　 　德阳东方电机技改