您好,登錄后才能下訂單哦!
本篇內(nèi)容介紹了“怎么用SpringBoot實現(xiàn)后端接口”的有關(guān)知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧!希望大家仔細閱讀,能夠?qū)W有所成!
所需依賴包
這里用的是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ù))都會進行安全校驗,參數(shù)校驗的重要性自然不必多說,那么如何對參數(shù)進行校驗就有講究了。
業(yè)務(wù)層校驗
首先我們來看一下最常見的做法,就是在業(yè)務(wù)層進行參數(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)然是沒有什么錯的,而且格式排版整齊也一目了然,不過這樣太繁瑣了,這還沒有進行業(yè)務(wù)操作呢光是一個參數(shù)校驗就已經(jīng)這么多行代碼,實在不夠優(yōu)雅。
我們來改進一下,使用Spring Validator和Hibernate Validator這兩套Validator來進行方便的參數(shù)校驗!這兩套Validator依賴包已經(jīng)包含在前面所說的web依賴包里了,所以可以直接使用。
Validator + BindResult進行校驗
Validator可以非常方便的制定校驗規(guī)則,并自動幫你完成校驗。首先在入?yún)⒗镄枰r灥淖侄渭由献⒔?每個注解對應(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 { @Autowired private 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),比如郵箱格式驗證,之前自己手寫正則表達式要寫那么一長串,還容易出錯,用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)達到我們想要的效果了,參數(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)然不可能再去手動捕捉異常進行處理,不然還不如用之前BindingResult方式呢。又不想手動捕捉這個異常,又要對這個異常進行處理,那正好使用SpringBoot全局異常處理來達到一勞永逸的效果!
基本使用
首先,我們需要新建一個類,在這個類上加上@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); // 然后提取錯誤提示信息進行返回 return objectError.getDefaultMessage(); } }
我們再來看下這次校驗失敗后的響應(yīng)數(shù)據(jù):
沒錯,這次返回的就是我們制定的錯誤提示信息!我們通過全局異常處理優(yōu)雅的實現(xiàn)了我們想要的功能!以后我們再想寫接口參數(shù)校驗,就只需要在入?yún)⒌某蓡T變量上加上Validator校驗規(guī)則注解,然后在參數(shù)上加上@Valid注解即可完成校驗,校驗失敗會自動返回錯誤提示信息,無需任何其他代碼!更多的校驗思路:SpringBoot實現(xiàn)通用的接口參數(shù)校驗
自定義異常
全局處理當(dāng)然不會只能處理一種異常,用途也不僅僅是對一個參數(shù)校驗方式進行優(yōu)化。在實際開發(fā)中,如何對異常處理其實是一個很麻煩的事情。傳統(tǒng)處理異常一般有以下煩惱:
是捕獲異常(try…catch)還是拋出異常(throws)
是在controller層做處理還是在service層處理又或是在dao層做處理
處理異常的方式是啥也不做,還是返回特定數(shù)據(jù),如果返回又返回什么數(shù)據(jù)
不是所有異常我們都能預(yù)先進行捕捉,如果發(fā)生了沒有捕捉到的異常該怎么辦?
以上這些問題都可以用全局異常處理來解決,全局異常處理也叫統(tǒng)一異常處理,全局和統(tǒng)一處理代表什么?代表規(guī)范!規(guī)范有了,很多問題就會迎刃而解!
全局異常處理的基本使用方式大家都已經(jīng)知道了,我們接下來更進一步的規(guī)范項目中的異常處理方式:自定義異常。
在很多情況下,我們需要手動拋出異常,比如在業(yè)務(wù)層當(dāng)有些條件并不符合業(yè)務(wù)邏輯,我這時候就可以手動拋出異常從而觸發(fā)事務(wù)回滾。那手動拋出異常最簡單的方式就是throw new RuntimeException("異常信息")了,不過使用自定義會更好一些:
自定義異常可以攜帶更多的信息,不像這樣只能攜帶一個字符串。
項目開發(fā)中經(jīng)常是很多人負(fù)責(zé)不同的模塊,使用自定義異??梢越y(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)體呢?關(guān)于異常的設(shè)計:如何更優(yōu)雅的設(shè)計異常
可以參考我們自定義異常類,也來一個響應(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)一化!這些可以參考:Java項目構(gòu)建基礎(chǔ):統(tǒng)一結(jié)果,統(tǒng)一異常,統(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進行增強操作,具體看代碼和注釋:
@RestControllerAdvice(basePackages = {"com.rudecrab.demo.controller"}) // 注意哦,這里要加上需要掃描的包 public class ResponseControllerAdvice implements ResponseBodyAdvice<Object> { @Override public boolean supports(MethodParameter returnType, Class<? extends HttpMessageConverter<?>> aClass) { // 如果接口返回的類型本身就是ResultVO那就沒有必要進行額外的操作,返回false return !returnType.getGenericParameterType().equals(ResultVO.class); } @Override public Object beforeBodyWrite(Object data, MethodParameter returnType, MediaType mediaType, Class<? extends HttpMessageConverter<?>> aClass, ServerHttpRequest request, ServerHttpResponse response) { // String類型不能直接包裝,所以要進行些特別的處理 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ù)進行返回前進行增強操作,supports方法要返回為true才會執(zhí)行beforeBodyWrite方法,所以如果有些情況不需要進行增強操作可以在supports方法里進行判斷。對返回數(shù)據(jù)進行真正的操作還是在beforeBodyWrite方法中,我們可以直接在該方法里包裝數(shù)據(jù),這樣就不需要每個接口都進行數(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進行包裝 return user; }
然后我們來看下響應(yīng)數(shù)據(jù):
成功對數(shù)據(jù)進行了包裝!
注意:beforeBodyWrite方法里包裝數(shù)據(jù)無法對String類型的數(shù)據(jù)直接進行強轉(zhuǎn),所以要進行特殊處理,這里不講過多的細節(jié),有興趣可以自行深入了解。
“怎么用SpringBoot實現(xiàn)后端接口”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實用文章!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。