前言

一個后端接口大致分為四個部分組成：接口地址（url）、接口請求方式（get、post等）、請求數(shù)據(jù)（request）、響應(yīng)數(shù)據(jù)（response）。如何構(gòu)建這幾個部分每個公司要求都不同，沒有什么“一定是最好的”標(biāo)準(zhǔn)，但一個優(yōu)秀的后端接口和一個糟糕的后端接口對比起來差異還是蠻大的，其中最重要的關(guān)鍵點就是看是否規(guī)范!

本文就一步一步演示如何構(gòu)建起一個優(yōu)秀的后端接口體系，體系構(gòu)建好了自然就有了規(guī)范，同時再構(gòu)建新的后端接口也會十分輕松。

在文章末尾貼上了項目演示的github地址，clone下來即可運行,并且我將每一次的優(yōu)化記錄都分別做了代碼提交，你可以清晰的看到項目的改進(jìn)過程！

所需依賴包

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

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

本文還用了swagger來生成API文檔，lombok來簡化類，不過這兩者不是必須的，可用可不用。

參數(shù)校驗

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

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

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

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?"郵箱格式不正確";}//?參數(shù)校驗完畢后這里就寫上業(yè)務(wù)邏輯return?"success";}

這樣做當(dāng)然是沒有什么錯的，而且格式排版整齊也一目了然，不過這樣太繁瑣了，這還沒有進(jìn)行業(yè)務(wù)操作呢光是一個參數(shù)校驗就已經(jīng)這么多行代碼，實在不夠優(yōu)雅。

我們來改進(jìn)一下，使用Spring Validator和Hibernate Validator這兩套Validator來進(jìn)行方便的參數(shù)校驗！這兩套Validator依賴包已經(jīng)包含在前面所說的web依賴包里了，所以可以直接使用。

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

Validator可以非常方便的制定校驗規(guī)則，并自動幫你完成校驗。首先在入?yún)⒗镄枰ｒ灥淖侄渭由献⒔?每個注解對應(yīng)不同的校驗規(guī)則，并可制定校驗失敗后的信息：

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

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

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

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

此時，業(yè)務(wù)層里的校驗代碼就已經(jīng)不需要了：

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

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

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

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

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

• 簡化代碼，之前業(yè)務(wù)層那么一大段校驗代碼都被省略掉了。

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

• 減少耦合度，使用Validator能夠讓業(yè)務(wù)層只關(guān)注業(yè)務(wù)邏輯，從基本的參數(shù)校驗邏輯中脫離出來。

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

這樣有點麻煩，并且重復(fù)代碼很多（盡管可以將這個重復(fù)代碼封裝成方法）。我們能否去掉BindingResult這一步呢？當(dāng)然是可以的！

Validator + 自動拋出異常

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

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

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

其實這樣就已經(jīng)達(dá)到我們想要的效果了，參數(shù)校驗不通過自然就不執(zhí)行接下來的業(yè)務(wù)邏輯，去掉BindingResult后會自動引發(fā)異常，異常發(fā)生了自然而然就不會執(zhí)行業(yè)務(wù)邏輯。也就是說，我們完全沒必要添加相關(guān)BindingResult相關(guān)操作嘛。

不過事情還沒有完，異常是引發(fā)了，可我們并沒有編寫返回錯誤信息的代碼呀，那參數(shù)校驗失敗了會響應(yīng)什么數(shù)據(jù)給前端呢？

我們來看一下剛才異常發(fā)生后接口響應(yīng)的數(shù)據(jù)：

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

全局異常處理

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

基本使用

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

然后在類中新建方法，在方法上加上@ExceptionHandler注解并指定你想處理的異常類型，接著在方法內(nèi)編寫對該異常的操作邏輯，就完成了對該異常的全局處理！

我們現(xiàn)在就來演示一下對參數(shù)校驗失敗拋出的MethodArgumentNotValidException全局處理：

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

我們再來看下這次校驗失敗后的響應(yīng)數(shù)據(jù)：

沒錯，這次返回的就是我們制定的錯誤提示信息！我們通過全局異常處理優(yōu)雅的實現(xiàn)了我們想要的功能！以后我們再想寫接口參數(shù)校驗，就只需要在入?yún)⒌某蓡T變量上加上Validator校驗規(guī)則注解，然后在參數(shù)上加上@Valid注解即可完成校驗，校驗失敗會自動返回錯誤提示信息，無需任何其他代碼！

自定義異常

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

• 是捕獲異常(try…catch)還是拋出異常(throws)

• 是在controller層做處理還是在service層處理又或是在dao層做處理

• 處理異常的方式是啥也不做，還是返回特定數(shù)據(jù)，如果返回又返回什么數(shù)據(jù)

• 不是所有異常我們都能預(yù)先進(jìn)行捕捉，如果發(fā)生了沒有捕捉到的異常該怎么辦？

以上這些問題都可以用全局異常處理來解決，全局異常處理也叫統(tǒng)一異常處理，全局和統(tǒng)一處理代表什么？代表規(guī)范！規(guī)范有了，很多問題就會迎刃而解！

全局異常處理的基本使用方式大家都已經(jīng)知道了，我們接下來更進(jìn)一步的規(guī)范項目中的異常處理方式：自定義異常。

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

• 自定義異常可以攜帶更多的信息，不像這樣只能攜帶一個字符串。

• 項目開發(fā)中經(jīng)常是很多人負(fù)責(zé)不同的模塊，使用自定義異常可以統(tǒng)一了對外異常展示的方式。

• 自定義異常語義更加清晰明了，一看就知道是項目中手動拋出的異常。

我們現(xiàn)在就來開始寫一個自定義異常：

@Getter?//只要getter方法，無需setter 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;} }

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

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

這樣就對異常的處理就比較規(guī)范了，當(dāng)然還可以添加對Exception的處理，這樣無論發(fā)生什么異常我們都能屏蔽掉然后響應(yīng)數(shù)據(jù)給前端，不過建議最后項目上線時這樣做，能夠屏蔽掉錯誤信息暴露給前端，在開發(fā)中為了方便調(diào)試還是不要這樣做。

現(xiàn)在全局異常處理和自定義異常已經(jīng)弄好了，不知道大家有沒有發(fā)現(xiàn)一個問題，就是當(dāng)我們拋出自定義異常的時候全局異常處理只響應(yīng)了異常中的錯誤信息msg給前端，并沒有將錯誤代碼code返回。這就要引申出我們接下來要講的東西了：數(shù)據(jù)統(tǒng)一響應(yīng)

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

現(xiàn)在我們規(guī)范好了參數(shù)校驗方式和異常處理方式，然而還沒有規(guī)范響應(yīng)數(shù)據(jù)！比如我要獲取一個分頁信息數(shù)據(jù)，獲取成功了呢自然就返回的數(shù)據(jù)列表，獲取失敗了后臺就會響應(yīng)異常信息，即一個字符串，就是說前端開發(fā)者壓根就不知道后端響應(yīng)過來的數(shù)據(jù)會是啥樣的！所以，統(tǒng)一響應(yīng)數(shù)據(jù)是前后端規(guī)范中必須要做的！

自定義統(tǒng)一響應(yīng)體

統(tǒng)一數(shù)據(jù)響應(yīng)第一步肯定要做的就是我們自己自定義一個響應(yīng)體類，無論后臺是運行正常還是發(fā)生異常，響應(yīng)給前端的數(shù)據(jù)格式是不變的！那么如何定義響應(yīng)體呢？

可以參考我們自定義異常類，也來一個響應(yīng)信息代碼code和響應(yīng)信息說明msg：

@Getter public?class?ResultVO<T>?{/***?狀態(tài)碼，比如1000代表響應(yīng)成功*/private?int?code;/***?響應(yīng)信息，用來說明響應(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ù)校驗失敗",?objectError.getDefaultMessage()); }

我們再來看一下此時如果發(fā)生異常了會響應(yīng)什么數(shù)據(jù)給前端：

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

@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)正確返回的是什么效果：

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

數(shù)據(jù)格式是規(guī)范了，不過響應(yīng)碼code和響應(yīng)信息msg還沒有規(guī)范呀！大家發(fā)現(xiàn)沒有，無論是正確響應(yīng)，還是異常響應(yīng)，響應(yīng)碼和響應(yīng)信息是想怎么設(shè)置就怎么設(shè)置，要是10個開發(fā)人員對同一個類型的響應(yīng)寫10個不同的響應(yīng)碼，那這個統(tǒng)一響應(yīng)體的格式規(guī)范就毫無意義！所以，必須要將響應(yīng)碼和響應(yīng)信息給規(guī)范起來。

響應(yīng)碼枚舉

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

@Getter public?enum?ResultCode?{SUCCESS(1000,?"操作成功"),FAILED(1001,?"響應(yīng)失敗"),VALIDATE_FAILED(1002,?"參數(shù)校驗失敗"),ERROR(5000,?"未知錯誤");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)碼枚舉來設(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; }

然后同時修改全局異常處理的響應(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ī)定的那幾個，就真正做到了響應(yīng)數(shù)據(jù)格式、響應(yīng)碼和響應(yīng)信息規(guī)范化、統(tǒng)一化！

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

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

首先，先創(chuàng)建一個類加上注解使其成為全局處理類。然后繼承ResponseBodyAdvice接口重寫其中的方法，即可對我們的controller進(jìn)行增強(qiáng)操作，具體看代碼和注釋：

@RestControllerAdvice(basePackages?=?{"com.rudecrab.demo.controller"})?//?注意哦，這里要加上需要掃描的包 public?class?ResponseControllerAdvice?implements?ResponseBodyAdvice<Object>?{@Overridepublic?boolean?supports(MethodParameter?returnType,?Class<??extends?HttpMessageConverter<?>>?aClass)?{//?如果接口返回的類型本身就是ResultVO那就沒有必要進(jìn)行額外的操作，返回falsereturn?!returnType.getGenericParameterType().equals(ResultVO.class);}@Overridepublic?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類型錯誤");}}//?將原本的數(shù)據(jù)包裝在ResultVO里return?new?ResultVO<>(data);} }

重寫的這兩個方法是用來在controller將數(shù)據(jù)進(jìn)行返回前進(jìn)行增強(qiáng)操作，supports方法要返回為true才會執(zhí)行beforeBodyWrite方法，所以如果有些情況不需要進(jìn)行增強(qiáng)操作可以在supports方法里進(jìn)行判斷。對返回數(shù)據(jù)進(jìn)行真正的操作還是在beforeBodyWrite方法中，我們可以直接在該方法里包裝數(shù)據(jù)，這樣就不需要每個接口都進(jìn)行數(shù)據(jù)包裝了，省去了很多麻煩。

我們可以現(xiàn)在去掉接口的數(shù)據(jù)包裝來看下效果：

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

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

成功對數(shù)據(jù)進(jìn)行了包裝！

“

注意：beforeBodyWrite方法里包裝數(shù)據(jù)無法對String類型的數(shù)據(jù)直接進(jìn)行強(qiáng)轉(zhuǎn)，所以要進(jìn)行特殊處理，這里不講過多的細(xì)節(jié)，有興趣可以自行深入了解。

總結(jié)

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

• 通過Validator + 自動拋出異常來完成了方便的參數(shù)校驗

• 通過全局異常處理 + 自定義異常完成了異常操作的規(guī)范

• 通過數(shù)據(jù)統(tǒng)一響應(yīng)完成了響應(yīng)數(shù)據(jù)的規(guī)范

• 多個方面組裝非常優(yōu)雅的完成了后端接口的協(xié)調(diào)，讓開發(fā)人員有更多的經(jīng)歷注重業(yè)務(wù)邏輯代碼，輕松構(gòu)建后端接口

再次強(qiáng)調(diào)，項目體系該怎么構(gòu)建、后端接口該怎么寫都沒有一個絕對統(tǒng)一的標(biāo)準(zhǔn)，不是說一定要按照本文的來才是最好的，你怎樣都可以，本文每一個環(huán)節(jié)你都可以按照自己的想法來進(jìn)行編碼，我只是提供了一個思路！

“

GitHub地址：https://github.com/RudeCrab/rude-java/tree/master/project-practice/validation-and-exception-handler

總結(jié)

以上是生活随笔為你收集整理的项目实践：Spring Boot 三招组合拳，手把手教你打出优雅的后端接口的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。