前言

一個(gè)后端接口大致分為四個(gè)部分組成：接口地址（url）扛禽、接口請(qǐng)求方式（get、post等）拆内、請(qǐng)求數(shù)據(jù)（request）旋圆、響應(yīng)數(shù)據(jù)（response）宠默。如何構(gòu)建這幾個(gè)部分每個(gè)公司要求都不同麸恍，沒(méi)有什么“一定是最好的”標(biāo)準(zhǔn)，但一個(gè)優(yōu)秀的后端接口和一個(gè)糟糕的后端接口對(duì)比起來(lái)差異還是蠻大的搀矫，其中最重要的關(guān)鍵點(diǎn)就是看是否規(guī)范!
本文就一步一步演示如何構(gòu)建起一個(gè)優(yōu)秀的后端接口體系抹沪，體系構(gòu)建好了自然就有了規(guī)范，同時(shí)再構(gòu)建新的后端接口也會(huì)十分輕松瓤球。
在文章末尾貼上了項(xiàng)目演示的github地址融欧，clone下來(lái)即可運(yùn)行,并且我將每一次的優(yōu)化記錄都分別做了代碼提交，你可以清晰的看到項(xiàng)目的改進(jìn)過(guò)程卦羡！

所需依賴包

這里用的是SpringBoot配置項(xiàng)目噪馏，本文講解的重點(diǎn)是后端接口麦到，所以只需要導(dǎo)入一個(gè)spring-boot-starter-web包就可以了：

<!--web依賴包，web應(yīng)用必備-->  
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

本文還用了swagger來(lái)生成API文檔欠肾，lombok來(lái)簡(jiǎn)化類瓶颠，不過(guò)這兩者不是必須的，可用可不用刺桃。

業(yè)務(wù)層校驗(yàn)

首先我們來(lái)看一下最常見的做法粹淋，就是在業(yè)務(wù)層進(jìn)行參數(shù)校驗(yàn)：

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

這樣做當(dāng)然是沒(méi)有什么錯(cuò)的，而且格式排版整齊也一目了然瑟慈，不過(guò)這樣太繁瑣了桃移，這還沒(méi)有進(jìn)行業(yè)務(wù)操作呢光是一個(gè)參數(shù)校驗(yàn)就已經(jīng)這么多行代碼，實(shí)在不夠優(yōu)雅葛碧。我們來(lái)改進(jìn)一下借杰，使用Spring Validator和Hibernate Validator這兩套Validator來(lái)進(jìn)行方便的參數(shù)校驗(yàn)！這兩套Validator依賴包已經(jīng)包含在前面所說(shuō)的web依賴包里了进泼，所以可以直接使用

Validator + BindResult進(jìn)行校驗(yàn)

Validator可以非常方便的制定校驗(yàn)規(guī)則第步，并自動(dòng)幫你完成校驗(yàn)。首先在入?yún)⒗镄枰ｒ?yàn)的字段加上注解,每個(gè)注解對(duì)應(yīng)不同的校驗(yàn)規(guī)則缘琅，并可制定校驗(yàn)失敗后的信息：

@Data
public class User {
    @NotNull(message = "用戶id不能為空")
    private Long id;

    @NotNull(message = "用戶賬號(hào)不能為空")
    @Size(min = 6, max = 11, message = "賬號(hào)長(zhǎng)度必須是6-11個(gè)字符")
    private String account;

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

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

校驗(yàn)規(guī)則和錯(cuò)誤提示信息配置完畢后粘都，接下來(lái)只需要在接口需要校驗(yàn)的參數(shù)上加上@Valid注解，并添加BindResult參數(shù)即可方便完成驗(yàn)證：

@RestController
@RequestMapping("user")
public class UserController {
    @Autowired
    private UserService userService;
    
    @PostMapping("/addUser")
    public String addUser(@RequestBody @Valid User user, BindingResult bindingResult) {
        // 如果有參數(shù)校驗(yàn)失敗刷袍，會(huì)將錯(cuò)誤信息封裝成對(duì)象組裝在BindingResult里
        for (ObjectError error : bindingResult.getAllErrors()) {
            return error.getDefaultMessage();
        }
        return userService.addUser(user);
    }
}

這樣當(dāng)請(qǐng)求數(shù)據(jù)傳遞到接口的時(shí)候Validator就自動(dòng)完成校驗(yàn)了翩隧，校驗(yàn)的結(jié)果就會(huì)封裝到BindingResult中去，如果有錯(cuò)誤信息我們就直接返回給前端呻纹，業(yè)務(wù)邏輯代碼也根本沒(méi)有執(zhí)行下去堆生。此時(shí)，業(yè)務(wù)層里的校驗(yàn)代碼就已經(jīng)不需要了：

public String addUser(User user) {
     // 直接編寫業(yè)務(wù)邏輯
     return "success";
 }

現(xiàn)在可以看一下參數(shù)校驗(yàn)效果雷酪。我們故意給這個(gè)接口傳遞一個(gè)不符合校驗(yàn)規(guī)則的參數(shù)淑仆，先傳遞一個(gè)錯(cuò)誤數(shù)據(jù)給接口，故意將password這個(gè)字段不滿足校驗(yàn)條件：

{
    "account": "12345678",
    "email": "123@qq.com",
    "id": 0,
    "password": "123"
}

再來(lái)看一下接口的響應(yīng)數(shù)據(jù)：

圖一

這樣是不是方便很多哥力？不難看出使用Validator校驗(yàn)有如下幾個(gè)好處：

• 簡(jiǎn)化代碼蔗怠，之前業(yè)務(wù)層那么一大段校驗(yàn)代碼都被省略掉了。
• 使用方便吩跋，那么多校驗(yàn)規(guī)則可以輕而易舉的實(shí)現(xiàn)寞射，比如郵箱格式驗(yàn)證，之前自己手寫正則表達(dá)式要寫那么一長(zhǎng)串锌钮，還容易出錯(cuò)桥温，用Validator直接一個(gè)注解搞定。（還有更多校驗(yàn)規(guī)則注解梁丘，可以自行去了解哦）
• 減少耦合度侵浸，使用Validator能夠讓業(yè)務(wù)層只關(guān)注業(yè)務(wù)邏輯旺韭，從基本的參數(shù)校驗(yàn)邏輯中脫離出來(lái)。

使用Validator+ BindingResult已經(jīng)是非常方便實(shí)用的參數(shù)校驗(yàn)方式了掏觉，在實(shí)際開發(fā)中也有很多項(xiàng)目就是這么做的茂翔，不過(guò)這樣還是不太方便，因?yàn)槟忝繉懸粋€(gè)接口都要添加一個(gè)BindingResult參數(shù)履腋，然后再提取錯(cuò)誤信息返回給前端珊燎。這樣有點(diǎn)麻煩，并且重復(fù)代碼很多（盡管可以將這個(gè)重復(fù)代碼封裝成方法）遵湖。我們能否去掉BindingResult這一步呢悔政？當(dāng)然是可以的！

Validator + 自動(dòng)拋出異常

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

@PostMapping("/addUser")
public String addUser(@RequestBody @Valid User user) {
    return userService.addUser(user);
}

去掉之后會(huì)發(fā)生什么事情呢延旧？直接來(lái)試驗(yàn)一下谋国，還是按照之前一樣故意傳遞一個(gè)不符合校驗(yàn)規(guī)則的參數(shù)給接口。 此時(shí)我們觀察控制臺(tái)可以發(fā)現(xiàn)接口已經(jīng)引發(fā)MethodArgumentNotValidException異常了：

圖二

其實(shí)這樣就已經(jīng)達(dá)到我們想要的效果了迁沫，參數(shù)校驗(yàn)不通過(guò)自然就不執(zhí)行接下來(lái)的業(yè)務(wù)邏輯芦瘾，去掉BindingResult后會(huì)自動(dòng)引發(fā)異常，異常發(fā)生了自然而然就不會(huì)執(zhí)行業(yè)務(wù)邏輯集畅。也就是說(shuō)近弟，我們完全沒(méi)必要添加相關(guān)BindingResult相關(guān)操作嘛。不過(guò)事情還沒(méi)有完挺智，異常是引發(fā)了祷愉，可我們并沒(méi)有編寫返回錯(cuò)誤信息的代碼呀，那參數(shù)校驗(yàn)失敗了會(huì)響應(yīng)什么數(shù)據(jù)給前端呢赦颇？
我們來(lái)看一下剛才異常發(fā)生后接口響應(yīng)的數(shù)據(jù)：

圖三

全局異常處理

參數(shù)校驗(yàn)失敗會(huì)自動(dòng)引發(fā)異常扇苞，我們當(dāng)然不可能再去手動(dòng)捕捉異常進(jìn)行處理欺殿，不然還不如用之前BindingResult方式呢。又不想手動(dòng)捕捉這個(gè)異常杨拐，又要對(duì)這個(gè)異常進(jìn)行處理祈餐，那正好使用SpringBoot全局異常處理來(lái)達(dá)到一勞永逸的效果擂啥！

基本使用

首先哄陶，我們需要新建一個(gè)類，在這個(gè)類上加上@ControllerAdvice或@RestControllerAdvice注解哺壶，這個(gè)類就配置成全局處理類了屋吨。（這個(gè)根據(jù)你的Controller層用的是@Controller還是@RestController來(lái)決定）
然后在類中新建方法蜒谤，在方法上加上@ExceptionHandler注解并指定你想處理的異常類型，接著在方法內(nèi)編寫對(duì)該異常的操作邏輯至扰，就完成了對(duì)該異常的全局處理鳍徽！
我們現(xiàn)在就來(lái)演示一下對(duì)參數(shù)校驗(yàn)失敗拋出的MethodArgumentNotValidException全局處理：

@RestControllerAdvice
public class ExceptionControllerAdvice {

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

我們?cè)賮?lái)看下這次校驗(yàn)失敗后的響應(yīng)數(shù)據(jù)：

圖四

沒(méi)錯(cuò)，這次返回的就是我們制定的錯(cuò)誤提示信息敢课！我們通過(guò)全局異常處理優(yōu)雅的實(shí)現(xiàn)了我們想要的功能阶祭！以后我們?cè)傧雽懡涌趨?shù)校驗(yàn)，就只需要在入?yún)⒌某蓡T變量上加上Validator校驗(yàn)規(guī)則注解直秆，然后在參數(shù)上加上@Valid注解即可完成校驗(yàn)濒募，校驗(yàn)失敗會(huì)自動(dòng)返回錯(cuò)誤提示信息，無(wú)需任何其他代碼圾结！

自定義異常

全局處理當(dāng)然不會(huì)只能處理一種異常瑰剃，用途也不僅僅是對(duì)一個(gè)參數(shù)校驗(yàn)方式進(jìn)行優(yōu)化。在實(shí)際開發(fā)中筝野，如何對(duì)異常處理其實(shí)是一個(gè)很麻煩的事情晌姚。傳統(tǒng)處理異常一般有以下煩惱：

• 是捕獲異常(try...catch)還是拋出異常(throws)
• 是在controller層做處理還是在service層處理又或是在dao層做處理
• 處理異常的方式是啥也不做，還是返回特定數(shù)據(jù)歇竟，如果返回又返回什么數(shù)據(jù)
• 不是所有異常我們都能預(yù)先進(jìn)行捕捉挥唠，如果發(fā)生了沒(méi)有捕捉到的異常該怎么辦？

以上這些問(wèn)題都可以用全局異常處理來(lái)解決焕议，全局異常處理也叫統(tǒng)一異常處理猛遍，全局和統(tǒng)一處理代表什么？ 代表規(guī)范号坡！ 規(guī)范有了懊烤，很多問(wèn)題就會(huì)迎刃而解！
全局異常處理的基本使用方式大家都已經(jīng)知道了宽堆，我們接下來(lái)更進(jìn)一步的規(guī)范項(xiàng)目中的異常處理方式：自定義異常腌紧。
在很多情況下，我們需要手動(dòng)拋出異常畜隶，比如在業(yè)務(wù)層當(dāng)有些條件并不符合業(yè)務(wù)邏輯壁肋，我這時(shí)候就可以手動(dòng)拋出異常從而觸發(fā)事務(wù)回滾。那手動(dòng)拋出異常最簡(jiǎn)單的方式就是throw new RuntimeException("異常信息")了籽慢，不過(guò)使用自定義會(huì)更好一些：

• 自定義異辰牛可以攜帶更多的信息，不像這樣只能攜帶一個(gè)字符串箱亿。
• 項(xiàng)目開發(fā)中經(jīng)常是很多人負(fù)責(zé)不同的模塊跛锌，使用自定義異常可以統(tǒng)一了對(duì)外異常展示的方式届惋。
• 自定義異常語(yǔ)義更加清晰明了髓帽，一看就知道是項(xiàng)目中手動(dòng)拋出的異常菠赚。
  我們現(xiàn)在就來(lái)開始寫一個(gè)自定義異常：

@Getter //只要getter方法，無(wú)需setter
public class APIException extends RuntimeException {
    private int code;
    private String msg;

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

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

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

在剛才的全局異常處理類中記得添加對(duì)我們自定義異常的處理：

@ExceptionHandler(APIException.class)
public String APIExceptionHandler(APIException e) {
    return e.getMsg();
}

這樣就對(duì)異常的處理就比較規(guī)范了郑藏，當(dāng)然還可以添加對(duì)Exception的處理衡查，這樣無(wú)論發(fā)生什么異常我們都能屏蔽掉然后響應(yīng)數(shù)據(jù)給前端，不過(guò)建議最后項(xiàng)目上線時(shí)這樣做必盖，能夠屏蔽掉錯(cuò)誤信息暴露給前端拌牲，在開發(fā)中為了方便調(diào)試還是不要這樣做。
現(xiàn)在全局異常處理和自定義異常已經(jīng)弄好了歌粥，不知道大家有沒(méi)有發(fā)現(xiàn)一個(gè)問(wèn)題们拙，就是當(dāng)我們拋出自定義異常的時(shí)候全局異常處理只響應(yīng)了異常中的錯(cuò)誤信息msg給前端，并沒(méi)有將錯(cuò)誤代碼code返回阁吝。這就要引申出我們接下來(lái)要講的東西了：數(shù)據(jù)統(tǒng)一響應(yīng)

數(shù)據(jù)統(tǒng)一響應(yīng)

現(xiàn)在我們規(guī)范好了參數(shù)校驗(yàn)方式和異常處理方式砚婆，然而還沒(méi)有規(guī)范響應(yīng)數(shù)據(jù)！比如我要獲取一個(gè)分頁(yè)信息數(shù)據(jù)突勇，獲取成功了呢自然就返回的數(shù)據(jù)列表装盯，獲取失敗了后臺(tái)就會(huì)響應(yīng)異常信息，即一個(gè)字符串甲馋，就是說(shuō)前端開發(fā)者壓根就不知道后端響應(yīng)過(guò)來(lái)的數(shù)據(jù)會(huì)是啥樣的埂奈！所以，統(tǒng)一響應(yīng)數(shù)據(jù)是前后端規(guī)范中必須要做的定躏！
自定義統(tǒng)一響應(yīng)體

統(tǒng)一數(shù)據(jù)響應(yīng)第一步肯定要做的就是我們自己自定義一個(gè)響應(yīng)體類账磺，無(wú)論后臺(tái)是運(yùn)行正常還是發(fā)生異常，響應(yīng)給前端的數(shù)據(jù)格式是不變的痊远！那么如何定義響應(yīng)體呢垮抗？可以參考我們自定義異常類，也來(lái)一個(gè)響應(yīng)信息代碼code和響應(yīng)信息說(shuō)明msg：

@Getter
public class ResultVO<T> {
    /**
     * 狀態(tài)碼碧聪，比如1000代表響應(yīng)成功
     */
    private int code;
    /**
     * 響應(yīng)信息冒版，用來(lái)說(shuō)明響應(yīng)情況
     */
    private String msg;
    /**
     * 響應(yīng)的具體數(shù)據(jù)
     */
    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) {
    // 注意哦，這里返回類型是自定義響應(yīng)體
    return new ResultVO<>(e.getCode(), "響應(yīng)失敗", e.getMsg());
}

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

我們?cè)賮?lái)看一下此時(shí)如果發(fā)生異常了會(huì)響應(yīng)什么數(shù)據(jù)給前端：

圖五

OK辞嗡，這個(gè)異常信息響應(yīng)就非常好了，狀態(tài)碼和響應(yīng)說(shuō)明還有錯(cuò)誤提示數(shù)據(jù)都返給了前端滞造，并且是所有異常都會(huì)返回相同的格式续室！異常這里搞定了，別忘了我們到接口那也要修改返回類型谒养，我們新增一個(gè)接口好來(lái)看看效果：

@GetMapping("/getUser")
public ResultVO<User> getUser() {
    User user = new User();
    user.setId(1L);
    user.setAccount("12345678");
    user.setPassword("12345678");
    user.setEmail("123@qq.com");
    
    return new ResultVO<>(user);
}

看一下如果響應(yīng)正確返回的是什么效果：

圖六

這樣無(wú)論是正確響應(yīng)還是發(fā)生異常挺狰，響應(yīng)數(shù)據(jù)的格式都是統(tǒng)一的，十分規(guī)范！

數(shù)據(jù)格式是規(guī)范了她渴，不過(guò)響應(yīng)碼code和響應(yīng)信息msg還沒(méi)有規(guī)范呀达址！大家發(fā)現(xiàn)沒(méi)有蔑祟，無(wú)論是正確響應(yīng)趁耗，還是異常響應(yīng)，響應(yīng)碼和響應(yīng)信息是想怎么設(shè)置就怎么設(shè)置疆虚，要是10個(gè)開發(fā)人員對(duì)同一個(gè)類型的響應(yīng)寫10個(gè)不同的響應(yīng)碼苛败，那這個(gè)統(tǒng)一響應(yīng)體的格式規(guī)范就毫無(wú)意義！所以径簿，必須要將響應(yīng)碼和響應(yīng)信息給規(guī)范起來(lái)罢屈。

響應(yīng)碼枚舉

要規(guī)范響應(yīng)體中的響應(yīng)碼和響應(yīng)信息用枚舉簡(jiǎn)直再恰當(dāng)不過(guò)了，我們現(xiàn)在就來(lái)創(chuàng)建一個(gè)響應(yīng)碼枚舉類：

@Getter
public enum ResultCode {

    SUCCESS(1000, "操作成功"),

    FAILED(1001, "響應(yīng)失敗"),

    VALIDATE_FAILED(1002, "參數(shù)校驗(yàn)失敗"),

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

    private int code;
    private String msg;

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

}

然后修改響應(yīng)體的構(gòu)造方法篇亭，讓其只準(zhǔn)接受響應(yīng)碼枚舉來(lái)設(shè)置響應(yīng)碼和響應(yīng)信息：

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;
}

然后同時(shí)修改全局異常處理的響應(yīng)碼設(shè)置方式：

@ExceptionHandler(APIException.class)
public ResultVO<String> APIExceptionHandler(APIException e) {
    // 注意哦缠捌，這里傳遞的響應(yīng)碼枚舉
    return new ResultVO<>(ResultCode.FAILED, e.getMsg());
}

@ExceptionHandler(MethodArgumentNotValidException.class)
public ResultVO<String> MethodArgumentNotValidExceptionHandler(MethodArgumentNotValidException e) {
    ObjectError objectError = e.getBindingResult().getAllErrors().get(0);
    // 注意哦，這里傳遞的響應(yīng)碼枚舉
    return new ResultVO<>(ResultCode.VALIDATE_FAILED, objectError.getDefaultMessage());
}

這樣響應(yīng)碼和響應(yīng)信息只能是枚舉規(guī)定的那幾個(gè)译蒂，就真正做到了響應(yīng)數(shù)據(jù)格式曼月、響應(yīng)碼和響應(yīng)信息規(guī)范化、統(tǒng)一化柔昼！

全局處理響應(yīng)數(shù)據(jù)

接口返回統(tǒng)一響應(yīng)體 + 異常也返回統(tǒng)一響應(yīng)體哑芹，其實(shí)這樣已經(jīng)很好了，但還是有可以優(yōu)化的地方捕透。要知道一個(gè)項(xiàng)目下來(lái)定義的接口搞個(gè)幾百個(gè)太正常不過(guò)了聪姿，要是每一個(gè)接口返回?cái)?shù)據(jù)時(shí)都要用響應(yīng)體來(lái)包裝一下好像有點(diǎn)麻煩，有沒(méi)有辦法省去這個(gè)包裝過(guò)程呢乙嘀？當(dāng)然是有滴末购，還是要用到全局處理。
首先虎谢，先創(chuàng)建一個(gè)類加上注解使其成為全局處理類招盲。然后繼承ResponseBodyAdvice接口重寫其中的方法，即可對(duì)我們的controller進(jìn)行增強(qiáng)操作嘉冒，具體看代碼和注釋：

@RestControllerAdvice(basePackages = {"com.rudecrab.demo.controller"}) // 注意哦曹货，這里要加上需要掃描的包
public class ResponseControllerAdvice implements ResponseBodyAdvice<Object> {
    @Override
    public boolean supports(MethodParameter returnType, Class<? extends HttpMessageConverter<?>> aClass) {
        // 如果接口返回的類型本身就是ResultVO那就沒(méi)有必要進(jìn)行額外的操作，返回false
        return !returnType.getParameterType().equals(ResultVO.class);
    }

    @Override
    public Object beforeBodyWrite(Object data, MethodParameter returnType, MediaType mediaType, Class<? extends HttpMessageConverter<?>> aClass, ServerHttpRequest request, ServerHttpResponse response) {
        // String類型不能直接包裝讳推，所以要進(jìn)行些特別的處理
        if (returnType.getGenericParameterType().equals(String.class)) {
            ObjectMapper objectMapper = new ObjectMapper();
            try {
                // 將數(shù)據(jù)包裝在ResultVO里后顶籽，再轉(zhuǎn)換為json字符串響應(yīng)給前端
                return objectMapper.writeValueAsString(new ResultVO<>(data));
            } catch (JsonProcessingException e) {
                throw new APIException("返回String類型錯(cuò)誤");
            }
        }
        // 將原本的數(shù)據(jù)包裝在ResultVO里
        return new ResultVO<>(data);
    }
}

重寫的這兩個(gè)方法是用來(lái)在controller將數(shù)據(jù)進(jìn)行返回前進(jìn)行增強(qiáng)操作，supports方法要返回為true才會(huì)執(zhí)行beforeBodyWrite方法银觅，所以如果有些情況不需要進(jìn)行增強(qiáng)操作可以在supports方法里進(jìn)行判斷礼饱。對(duì)返回?cái)?shù)據(jù)進(jìn)行真正的操作還是在beforeBodyWrite方法中，我們可以直接在該方法里包裝數(shù)據(jù)，這樣就不需要每個(gè)接口都進(jìn)行數(shù)據(jù)包裝了镊绪，省去了很多麻煩匀伏。
我們可以現(xiàn)在去掉接口的數(shù)據(jù)包裝來(lái)看下效果：

@GetMapping("/getUser")
public User getUser() {
    User user = new User();
    user.setId(1L);
    user.setAccount("12345678");
    user.setPassword("12345678");
    user.setEmail("123@qq.com");
    // 注意哦，這里是直接返回的User類型蝴韭，并沒(méi)有用ResultVO進(jìn)行包裝
    return user;
}

然后我們來(lái)看下響應(yīng)數(shù)據(jù)：

圖七

總結(jié)

自此整個(gè)后端接口基本體系就構(gòu)建完畢了

• 通過(guò)Validator + 自動(dòng)拋出異常來(lái)完成了方便的參數(shù)校驗(yàn)
• 通過(guò)全局異常處理 + 自定義異常完成了異常操作的規(guī)范
• 通過(guò)數(shù)據(jù)統(tǒng)一響應(yīng)完成了響應(yīng)數(shù)據(jù)的規(guī)范
• 多個(gè)方面組裝非常優(yōu)雅的完成了后端接口的協(xié)調(diào)庆尘，讓開發(fā)人員有更多的經(jīng)歷注重* 業(yè)務(wù)邏輯代碼剃诅，輕松構(gòu)建后端接口

再次強(qiáng)調(diào)，項(xiàng)目體系該怎么構(gòu)建驶忌、后端接口該怎么寫都沒(méi)有一個(gè)絕對(duì)統(tǒng)一的標(biāo)準(zhǔn)矛辕，不是說(shuō)一定要按照本文的來(lái)才是最好的，你怎樣都可以付魔，本文每一個(gè)環(huán)節(jié)你都可以按照自己的想法來(lái)進(jìn)行編碼聊品，我只是提供了一個(gè)思路！
最后在這里放上此項(xiàng)目的github地址抒抬，clone到本地即可直接運(yùn)行杨刨，并且我將每一次的優(yōu)化記錄都分別做了代碼提交，你可以清晰的看到項(xiàng)目的改進(jìn)過(guò)程擦剑，如果對(duì)你有幫助請(qǐng)?jiān)趃ithub上點(diǎn)個(gè)star妖胀，我還會(huì)繼續(xù)更新很多【項(xiàng)目實(shí)踐】哦！
作者：RudeCrab
來(lái)源：juejin.im/post/6844904101940117511