SpringBoot實現優雅的後端接口

SpringBoot實現優雅的後端接口

一個後端接口大致分爲四個部分組成：接口地址（url）、接口請求方式（get、post等）、請求數據（request）、響應數據（response）。如何構建這幾個部分每個人的習慣都不同，沒有什麼“一定是最好的”標準。

這裏用的是SpringBoot配置項目，重點是後端接口，所以只需要導入一個spring-boot-starter-web包就可以了：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.2.2.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <groupId>com.wh</groupId>
    <artifactId>validation-and-exception-handler</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <java.version>1.8</java.version>
    </properties>

    <dependencies>
        <!--web依賴包，web應用必備-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <!--lombok依賴包，簡化類。非必須導入-->
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
            <exclusions>
                <exclusion>
                    <groupId>org.junit.vintage</groupId>
                    <artifactId>junit-vintage-engine</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>



</project>

參數校驗

一個接口一般對參數（請求數據）都會進行安全校驗，參數校驗的重要性自然不必多說，那麼如何對參數進行校驗就有講究了。

業務層校驗

首先我們來看一下最常見的做法，就是在業務層進行參數校驗：

public String addUser(User user) {
     if (user == null || user.getId() == null || user.getAccount() == null || user.getPassword() == null || user.getEmail() == null) {
         return "對象或者對象字段不能爲空";
     }
     if (StringUtils.isEmpty(user.getAccount()) || StringUtils.isEmpty(user.getPassword()) || StringUtils.isEmpty(user.getEmail())) {
         return "不能輸入空字符串";
     }
     if (user.getAccount().length() < 6 || user.getAccount().length() > 11) {
         return "賬號長度必須是6-11個字符";
     }
     if (user.getPassword().length() < 6 || user.getPassword().length() > 16) {
         return "密碼長度必須是6-16個字符";
     }
     if (!Pattern.matches("^[a-zA-Z0-9_-]+@[a-zA-Z0-9_-]+(\\.[a-zA-Z0-9_-]+)+$", user.getEmail())) {
         return "郵箱格式不正確";
     }
     // 參數校驗完畢後這裏就寫上業務邏輯
     return "success";
 }

這樣做當然是沒有什麼錯的，而且格式排版整齊也一目瞭然，不過這樣太繁瑣了，這還沒有進行業務操作呢光是一個參數校驗就已經這麼多行代碼，實在不夠優雅。

改進一下，使用Spring Validator和Hibernate Validator這兩套Validator來進行方便的參數校驗！這兩套Validator依賴包已經包含在前面所說的web依賴包裏了，所以可以直接使用。

Validator + BindResult進行校驗

Validator可以非常方便的制定校驗規則，並自動幫你完成校驗。首先在入參裏需要校驗的字段加上註解,每個註解對應不同的校驗規則，並可制定校驗失敗後的信息：

package com.wh.entity;

import lombok.Data;

import javax.validation.constraints.Email;
import javax.validation.constraints.NotNull;
import javax.validation.constraints.Size;

/**
 * @author wh
 * @date 2020/5/5 19:22
 * @description
 * Spring Validator和Hibernate Validator這兩套Validator來進行方便的參數校驗！
 * 這兩套Validator依賴包已經包含在前面所說的web依賴包裏了，所以可以直接使用。
 *
 * Validator + BindResult進行校驗
 * Validator可以非常方便的制定校驗規則，並自動幫你完成校驗。
 * 首先在入參裏需要校驗的字段加上註解,每個註解對應不同的校驗規則，並可制定校驗失敗後的信息：
 */
@Data
public class User {
    @NotNull(message = "用戶id不能爲空")
    private Long id;

    @NotNull(message = "用戶賬號不能爲空")
    @Size(min = 6, max = 11, message = "賬號長度必須是6-11個字符")
    private String account;

    @NotNull(message = "用戶密碼不能爲空")
    @Size(min = 6, max = 11, message = "密碼長度必須是6-16個字符")
    private String password;

    @NotNull(message = "用戶郵箱不能爲空")
    @Email(message = "郵箱格式不正確")
    private String email;
}

校驗規則和錯誤提示信息配置完畢後，接下來只需要在接口需要校驗的參數上加上@Valid註解，並添加BindResult參數即可方便完成驗證：

package com.wh.controller;

import com.wh.entity.User;
import com.wh.service.UserService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.validation.BindingResult;
import org.springframework.validation.ObjectError;
import org.springframework.web.bind.annotation.*;

import javax.validation.Valid;
import java.util.ArrayList;
import java.util.List;

/**
 * @author wh
 * @date 2020/5/5 19:27
 * @description
 */
@RestController
@RequestMapping("user")
public class UserController {
    @Autowired
    private UserService userService;

    @PostMapping("/addUser")
    public String addUser(@RequestBody @Valid User user, BindingResult bindingResult) {
        // 如果有參數校驗失敗，會將錯誤信息封裝成對象組裝在BindingResult裏
        for (ObjectError error : bindingResult.getAllErrors()){
            return error.getDefaultMessage();
        }
        return userService.addUser(user);
    }

}

這樣當請求數據傳遞到接口的時候Validator就自動完成校驗了，校驗的結果就會封裝到BindingResult中去，如果有錯誤信息我們就直接返回給前端，業務邏輯代碼也根本沒有執行下去。

此時，業務層裏的校驗代碼就已經不需要了：

package com.wh.service.impl;

import com.wh.entity.User;
import com.wh.service.UserService;
import org.springframework.stereotype.Service;

/**
 * @author wh
 * @date 2020/5/5 19:29
 * @description
 */
@Service
public class UserServiceImpl implements UserService {
    @Override
    public String addUser(User user) {
        // 直接編寫業務邏輯
        return "success";
    }
}

現在可以看一下參數校驗效果。這裏故意給這個接口傳遞一個不符合校驗規則的參數，先傳遞一個錯誤數據給接口，故意將password這個字段不滿足校驗條件：

這樣看來確實是方便很多，不難看出使用Validator校驗有如下幾個好處：

• 簡化代碼，之前業務層那麼一大段校驗代碼都被省略掉了。

• 使用方便，那麼多校驗規則可以輕而易舉的實現，比如郵箱格式驗證，之前自己手寫正則表達式要寫那麼一長串，還容易出錯，用Validator直接一個註解搞定。（還有更多校驗規則註解，可以自行去了解哦）

• 減少耦合度，使用Validator能夠讓業務層只關注業務邏輯，從基本的參數校驗邏輯中脫離出來。

使用Validator+ BindingResult已經是非常方便實用的參數校驗方式了，在實際開發中也有很多項目就是這麼做的，不過這樣還是不太方便，因爲你每寫一個接口都要添加一個BindingResult參數，然後再提取錯誤信息返回給前端。

這樣有點麻煩，並且重複代碼很多（儘管可以將這個重複代碼封裝成方法）。我們能否去掉BindingResult這一步呢？當然是可以的！

Validator + 自動拋出異常

我們完全可以將BindingResult這一步給去掉：

package com.wh.controller;

import com.wh.entity.User;
import com.wh.service.UserService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.validation.BindingResult;
import org.springframework.validation.ObjectError;
import org.springframework.web.bind.annotation.*;

import javax.validation.Valid;
import java.util.ArrayList;
import java.util.List;

/**
 * @author wh
 * @date 2020/5/5 19:27
 * @description
 */
@RestController
@RequestMapping("user")
public class UserController {
    @Autowired
    private UserService userService;

    @PostMapping("/addUser")
    public String addUser(@RequestBody @Valid User user) {
        // 如果有參數校驗失敗，會將錯誤信息封裝成對象組裝在BindingResult裏
        return userService.addUser(user);
    }

}

去掉之後會發生什麼事情呢？

此時我們觀察控制檯可以發現接口已經引發MethodArgumentNotValidException異常了：

再來看一下剛纔異常發生後接口響應的數據：

這裏直接將整個錯誤對象相關信息都響應給前端了！這樣就很難受，不過解決這個問題也很簡單，就是我們接下來要講的全局異常處理！

全局異常處理

參數校驗失敗會自動引發異常，我們當然不可能再去手動捕捉異常進行處理，不然還不如用之前BindingResult方式呢。又不想手動捕捉這個異常，又要對這個異常進行處理，那正好使用SpringBoot全局異常處理來達到一勞永逸的效果！

首先，我們需要新建一個類，在這個類上加上@ControllerAdvice或@RestControllerAdvice註解，這個類就配置成全局處理類了。（這個根據你的Controller層用的是@Controller還是@RestController來決定）

然後在類中新建方法，在方法上加上@ExceptionHandler註解並指定你想處理的異常類型，接着在方法內編寫對該異常的操作邏輯，就完成了對該異常的全局處理！

現在就來演示一下對參數校驗失敗拋出的MethodArgumentNotValidException全局處理：

package com.wh.config;

import org.springframework.validation.ObjectError;
import org.springframework.web.bind.MethodArgumentNotValidException;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RestControllerAdvice;

/**
 * @author wh
 * @date 2020/5/5 19:55
 * @description
 */
@RestControllerAdvice
public class ExceptionControllerAdvice {

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public String MethodArgumentNotValidExceptionHandler(MethodArgumentNotValidException e) {
        // 從異常對象中拿到ObjectError對象
        ObjectError error = e.getBindingResult().getAllErrors().get(0);
        // 然後提取錯誤提示信息進行返回
        return error.getDefaultMessage();
    }
}

再來看下這次校驗失敗後的響應數據：

沒錯，這次返回的就是我們制定的錯誤提示信息！我們通過全局異常處理優雅的實現了我們想要的功能！以後我們再想寫接口參數校驗，就只需要在入參的成員變量上加上Validator校驗規則註解，然後在參數上加上@Valid註解即可完成校驗，校驗失敗會自動返回錯誤提示信息，無需任何其他代碼！

自定義異常

全局處理當然不會只能處理一種異常，用途也不僅僅是對一個參數校驗方式進行優化。在實際開發中，如何對異常處理其實是一個很麻煩的事情。傳統處理異常一般有以下煩惱：

• 是捕獲異常(try…catch)還是拋出異常(throws)
• 是在controller層做處理還是在service層處理又或是在dao層做處理
• 處理異常的方式是啥也不做，還是返回特定數據，如果返回又返回什麼數據
• 不是所有異常我們都能預先進行捕捉，如果發生了沒有捕捉到的異常該怎麼辦？

以上這些問題都可以用全局異常處理來解決，全局異常處理也叫統一異常處理，全局和統一處理代表什麼？代表規範！規範有了，很多問題就會迎刃而解！

接下來更進一步的規範項目中的異常處理方式：自定義異常。

在很多情況下，我們需要手動拋出異常，比如在業務層當有些條件並不符合業務邏輯，我這時候就可以手動拋出異常從而觸發事務回滾。那手動拋出異常最簡單的方式就是throw new RuntimeException(“異常信息”)了，不過使用自定義會更好一些：

• 自定義異常可以攜帶更多的信息，不像這樣只能攜帶一個字符串。
• 項目開發中經常是很多人負責不同的模塊，使用自定義異常可以統一了對外異常展示的方式。
• 自定義異常語義更加清晰明瞭，一看就知道是項目中手動拋出的異常。

現在就來開始寫一個自定義異常：

package com.wh.exception;

import lombok.Getter;

/**
 * @author wh
 * @date 2020/5/5 20:04
 * @description 自定義異常
 */
@Getter
public class APIException extends RuntimeException {
    private int code;
    private String msg;

    public APIException() {
        this(1001, "接口錯誤");
    }

    public APIException(String msg) {
        this(1001, msg);
    }

    public APIException(int code, String msg) {
        super(msg);
        this.code = code;
        this.msg = msg;
    }

}

在剛纔的全局異常處理類中記得添加對我們自定義異常的處理：

這樣就對異常的處理就比較規範了，當然還可以添加對Exception的處理，這樣無論發生什麼異常我們都能屏蔽掉然後響應數據給前端，不過建議最後項目上線時這樣做，能夠屏蔽掉錯誤信息暴露給前端，在開發中爲了方便調試還是不要這樣做。

現在全局異常處理和自定義異常已經弄好了，但是還有一個問題，就是當我們拋出自定義異常的時候全局異常處理只響應了異常中的錯誤信息msg給前端，並沒有將錯誤代碼code返回。這就要引申出一個新的東西：數據統一響應

數據統一響應

規範好了參數校驗方式和異常處理方式，然而還沒有規範響應數據！比如我要獲取一個分頁信息數據，獲取成功了呢自然就返回的數據列表，獲取失敗了後臺就會響應異常信息，即一個字符串，就是說前端開發者壓根就不知道後端響應過來的數據會是啥樣的！所以，統一響應數據是前後端規範中必須要做的！

自定義統一響應體

統一數據響應第一步肯定要做的就是我們自己自定義一個響應體類，無論後臺是運行正常還是發生異常，響應給前端的數據格式是不變的！那麼如何定義響應體呢？關於異常的設計：如何更優雅的設計異常

可以參考自定義異常類，也來一個響應信息代碼code和響應信息說明msg：

package com.wh.vo;

import lombok.Getter;

/**
 * @author wh
 * @date 2020/5/5 20:12
 * @description  自定義統一響應體
 */

@Getter
public class ResultVO<T> {
    /**
     * 狀態碼，比如1000代表響應成功
     */
    private int code;

    /**
     * 響應信息，用來說明響應情況
     */
    private String msg;

    /**
     * 響應的具體數據
     */
    private T data;

    public ResultVO(T data) {
        this(1000, "success", data);
    }

    public ResultVO(int code, String msg, T data) {
        this.code = code;
        this.msg = msg;
        this.data = data;
    }
}

然後我們修改一下全局異常處理那的返回值：

@ExceptionHandler(APIException.class)
public ResultVO<String> APIExceptionHandler(APIException e) {
    // 注意哦，這裏返回類型是自定義響應體
    return new ResultVO<>(e.getCode(), "響應失敗", e.getMsg());
}

@ExceptionHandler(MethodArgumentNotValidException.class)
public ResultVO<String> MethodArgumentNotValidExceptionHandler(MethodArgumentNotValidException e) {
    ObjectError objectError = e.getBindingResult().getAllErrors().get(0);
    // 注意哦，這裏返回類型是自定義響應體
    return new ResultVO<>(1001, "參數校驗失敗", objectError.getDefaultMessage());
}

再來看一下此時如果發生異常了會響應什麼數據給前端：

OK，這個異常信息響應就非常好了，狀態碼和響應說明還有錯誤提示數據都返給了前端，並且是所有異常都會返回相同的格式！異常這裏搞定了,接口那也要修改返回類型，新增一個接口好來看看效果：

 @GetMapping("/getUser")
    public ResultVO<User> getUser() {
        User user = new User();
        user.setId(1L);
        user.setAccount("12345678");
        user.setPassword("12345678");
        user.setEmail("[email protected]");

        return new ResultVO<>(user);
    }

看一下如果響應正確返回的是什麼效果：

這樣無論是正確響應還是發生異常，響應數據的格式都是統一的，十分規範！

數據格式是規範了，不過響應碼code和響應信息msg還沒有規範呀！可以發現，無論是正確響應，還是異常響應，響應碼和響應信息是想怎麼設置就怎麼設置，要是10個開發人員對同一個類型的響應寫10個不同的響應碼，那這個統一響應體的格式規範就毫無意義！所以，必須要將響應碼和響應信息給規範起來。

響應碼枚舉

要規範響應體中的響應碼和響應信息用枚舉簡直再恰當不過了，我們現在就來創建一個響應碼枚舉類：

package com.wh.enums;

import lombok.Getter;

/**
 * @author wh
 * @date 2020/5/5 20:33
 * @description 響應碼枚舉
 */
@Getter
public enum  ResultCode {
    SUCCESS(1000, "操作成功"),

    FAILED(1001, "響應失敗"),

    VALIDATE_FAILED(1002, "參數校驗失敗"),

    ERROR(5000, "未知錯誤");

    private int code;
    private String msg;

    ResultCode(int code, String msg) {
        this.code = code;
        this.msg = msg;
    }
}

修改響應體的構造方法，讓其只准接受響應碼枚舉來設置響應碼和響應信息：

 public ResultVO(T data) {
        this(ResultCode.SUCCESS, data);
    }

    public ResultVO(ResultCode resultCode, T data) {
        this.code = resultCode.getCode();
        this.msg = resultCode.getMsg();
        this.data = data;
    }

同時修改全局異常處理的響應碼設置方式：

@RestControllerAdvice
public class ExceptionControllerAdvice {


    @ExceptionHandler(APIException.class)
    public ResultVO<String> APIExceptionHandler(APIException e) {

        //這裏返回類型是自定義響應體
        return new ResultVO<>(ResultCode.FAILED, e.getMsg());
    }

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResultVO<String> MethodArgumentNotValidExceptionHandler(MethodArgumentNotValidException e) {
        ObjectError objectError = e.getBindingResult().getAllErrors().get(0);
        // 注意哦，這裏返回類型是自定義響應體
        return new ResultVO<>(ResultCode.VALIDATE_FAILED, objectError.getDefaultMessage());
    }
}

這樣響應碼和響應信息只能是枚舉規定的那幾個，就真正做到了響應數據格式、響應碼和響應信息規範化、統一化！

全局處理響應數據

接口返回統一響應體 + 異常也返回統一響應體，其實這樣已經很好了，但還是有可以優化的地方。要知道一個項目下來定義的接口搞個幾百個太正常不過了，要是每一個接口返回數據時都要用響應體來包裝一下好像有點麻煩，有沒有辦法省去這個包裝過程呢？當然是有滴，還是要用到全局處理。

首先，先創建一個類加上註解使其成爲全局處理類。然後繼承ResponseBodyAdvice接口重寫其中的方法，即可對我們的controller進行增強操作，具體看代碼和註釋：

package com.wh.config;

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.wh.exception.APIException;
import com.wh.vo.ResultVO;
import org.springframework.core.MethodParameter;
import org.springframework.http.MediaType;
import org.springframework.http.converter.HttpMessageConverter;
import org.springframework.http.server.ServerHttpRequest;
import org.springframework.http.server.ServerHttpResponse;
import org.springframework.web.bind.annotation.RestControllerAdvice;
import org.springframework.web.servlet.mvc.method.annotation.ResponseBodyAdvice;


/**
 * @author wh
 * @date 2020/5/5 20:38
 * @description
 */
@RestControllerAdvice(basePackages = {"com.wh.controller"})
public class ResponseControllerAdvice implements ResponseBodyAdvice<Object> {
    @Override
    public boolean supports(MethodParameter returnType, Class<? extends HttpMessageConverter<?>> aClass) {
        // 如果接口返回的類型本身就是ResultVO那就沒有必要進行額外的操作，返回false
        return !returnType.getParameterType().equals(ResultVO.class);
    }

    @Override
    public Object beforeBodyWrite(Object data, MethodParameter returnType, MediaType mediaType, Class<? extends HttpMessageConverter<?>> aClass, ServerHttpRequest serverHttpRequest, ServerHttpResponse serverHttpResponse) {
        // String類型不能直接包裝，所以要進行些特別的處理
        if (returnType.getGenericParameterType().equals(String.class)) {
            ObjectMapper objectMapper = new ObjectMapper();
            try {
                // 將數據包裝在ResultVO裏後，再轉換爲json字符串響應給前端
                return objectMapper.writeValueAsString(new ResultVO<>(data));
            } catch (JsonProcessingException e) {
                throw new APIException("返回String類型錯誤");
            }
        }
        // 將原本的數據包裝在ResultVO裏
        return new ResultVO<>(data);
    }
}

重寫的這兩個方法是用來在controller將數據進行返回前進行增強操作，supports方法要返回爲true纔會執行beforeBodyWrite方法，所以如果有些情況不需要進行增強操作可以在supports方法裏進行判斷。對返回數據進行真正的操作還是在beforeBodyWrite方法中，我們可以直接在該方法裏包裝數據，這樣就不需要每個接口都進行數據包裝了，省去了很多麻煩。

可以現在去掉接口的數據包裝來看下效果：

成功對數據進行了包裝！

注意：beforeBodyWrite方法裏包裝數據無法對String類型的數據直接進行強轉，所以要進行特殊處理，這裏不講過多的細節，有興趣可以自行深入瞭解。

總結

• 通過Validator + 自動拋出異常來完成了方便的參數校驗
• 通過全局異常處理 + 自定義異常完成了異常操作的規範
• 通過數據統一響應完成了響應數據的規範
• 多個方面組裝非常優雅的完成了後端接口的協調，讓開發人員有更多的經歷注重業務邏輯代碼，輕鬆構建後端接口

項目體系該怎麼構建、後端接口該怎麼寫都沒有一個絕對統一的標準，本文主要是記錄自己的一個學習過程。