Standardmäßig verfügt SpringBoot über die folgenden drei Rückgabesituationen.
@GetMapping("/getUserName") public String getUserName(){ return "HuaGe"; }
zurückzugeben. Rufen Sie die Schnittstelle auf, um das Ergebnis zurückzugeben:
HuaGe
@GetMapping("/getUserName") public User getUserName(){ return new User("HuaGe",18,"男"); }zurückzugeben
Das vom Aufruf der Schnittstelle zurückgegebene Ergebnis:
{ "name": "HuaGe", "age": "18", "性别": "男", }
@GetMapping("/getUserName") public static String getUserName(){ HashMap hashMap = Maps.newHashMap(); return hashMap.get(0).toString(); }
Simulieren Sie eine Nullzeigerausnahme ohne Ausnahmebehandlung, wie Sie sehen können# 🎜🎜 Das Standardrückgabeergebnis von #SpringBoot:
{ "timestamp": "2021-08-09T06:56:41.524+00:00", "status": 500, "error": "Internal Server Error", "path": "/sysUser/getUserName" }Wenn in den oben genannten Situationen das gesamte Projekt kein einheitliches Rückgabeformat definiert, definieren fünf Backend-Entwickler fünf Rückgabeformate, die nicht nur die Der Code ist aufgebläht, die Front-End- und Back-End-Docking-Effizienz ist gering und es können unerwartete Situationen auftreten, z. B. dass das Front-End direkt abnormale Details anzeigt usw. Dies führt zu einer sehr schlechten Benutzererfahrung. 2. Grundlegendes Gameplay Am häufigsten wird in Projekten eine Tool-Klasse gekapselt, die zurückgegeben werden muss, und zwar in der Klasse und der Schnittstelle Informationen, die an das Front-End zurückgegeben werden müssen, werden übergeben. Diese Klasse ist gekapselt, sodass das Phänomen inkonsistenter Rückgabeformate gelöst werden kann. 2.1 Parameterbeschreibung
Code: Statuscode, der Hintergrund kann einen einheitlichen Satz von Statuscodes verwalten ;
Beschreibungsinformationen, Informationen zu Schnittstellenaufrufen/Fehlern; Daten:
Daten zurückgeben.2.2 Prozessbeschreibung
public class Result<T> { private int code; private String message; private T data; public Result() {} public Result(int code, String message) { this.code = code; this.message = message; } /** * 成功 */ public static <T> Result<T> success(T data) { Result<T> result = new Result<T>(); result.setCode(ResultMsgEnum.SUCCESS.getCode()); result.setMessage(ResultMsgEnum.SUCCESS.getMessage()); result.setData(data); return result; } /** * 失败 */ public static <T> Result<T> error(int code, String message) { return new Result(code, message); } }Definition Rückgabestatuscode
public enum ResultMsgEnum { SUCCESS(0, "成功"), FAIL(-1, "失败"), AUTH_ERROR(502, "授权失败!"), SERVER_BUSY(503, "服务器正忙,请稍后再试!"), DATABASE_OPERATION_FAILED(504, "数据库操作失败"); private int code; private String message; ResultMsgEnum(int code, String message) { this.code = code; this.message = message; } public int getCode() { return this.code; } public String getMessage() { return this.message; } }
Verwendung# 🎜 🎜 #
Die beiden oben genannten Schritte definieren Datenrückgabeformat
und Statuscode
, schauen wir uns als nächstes die Vorgehensweise an Verwenden Sie es in der Schnittstelle. @GetMapping("/getUserName")
public Result getUserName(){
return Result.success("huage");
}
Das Aufrufergebnis ist wie folgt. Sie können sehen, dass es sich um den Parametertyp handelt, den wir in Ergebnis definiert haben.
{ "code": 0, "message": "成功", "data": "huage" }
Result.success in jeder Schnittstelle zum Packen der Rückgabeinformationen führt zu einer Menge wiederholtem Code, der nicht elegant genug und sogar peinlich genug ist, um anzugeben. Es muss eine Möglichkeit geben, den Code erneut zu verbessern und die optimale Lösung zu erreichen.
3. Erweiterte Verwendung数据返回格式
和状态码
,接下来就要看下在接口中如何使用了。
@RestControllerAdvice public class ResponseAdvice implements ResponseBodyAdvice<Object> { @Autowired private ObjectMapper objectMapper; /** * 是否开启功能 true:是 */ @Override public boolean supports(MethodParameter methodParameter, Class<? extends HttpMessageConverter<?>> aClass) { return true; } /** * 处理返回结果 */ @Override public Object beforeBodyWrite(Object o, MethodParameter methodParameter, MediaType mediaType, Class<? extends HttpMessageConverter<?>> aClass, ServerHttpRequest serverHttpRequest, ServerHttpResponse serverHttpResponse) { //处理字符串类型数据 if(o instanceof String){ try { return objectMapper.writeValueAsString(Result.success(o)); } catch (JsonProcessingException e) { e.printStackTrace(); } } return Result.success(o); } }
调用结果如下,可以看到是我们在Result中定义的参数类型。
{ "code": 0, "message": "成功", "data": { "timestamp": "2021-08-09T09:33:26.805+00:00", "status": 405, "error": "Method Not Allowed", "path": "/sysUser/getUserName" } }
这样写虽然能够满足日常需求,而且我相信很多小伙伴也是这么用的,但是如果我们有大量的接口,然后在每一个接口中都使用Result.success
来包装返回信息,会新增很多重复代码,显得不够优雅,甚至都不好意思拿出去显摆。 肯定会有一种方式能够再一次提高代码逼格,实现最优解。
基本用法学会后,接下来看点究极版本,主要用到如下两个知识点,用法简单,无论是拿出来教学妹,还是指点小姐姐,都是必备技能。
ResponseBodyAdvice: 该接口是SpringMVC 4.1提供的,它允许在 执行 @ResponseBody
后自定义返回数据,用来封装统一数据格式返回;
@RestControllerAdvice: 该注解是对Controller进行增强的,可以全局捕获抛出的异常。
新建ResponseAdvice
类;
实现ResponseBodyAdvice
接口,实现supports
、beforeBodyWrite
方法;
该类用于统一封装controller中接口的返回结果。
@RestControllerAdvice public class CustomerExceptionHandler { }
我们可以通过getUserName
接口测试一下,会发现和直接使用Result
返回的结果是一致的。
不过,细心的小伙伴们肯定注意到了,在ResponseAdvice
我们全部使用了Result.success(o)
来处理结果,对于error类型的结果未做处理。我们来看下,发生异常情况时,返回结果是什么样呢?继续使用上面HashMap空指针异常的代码,测试结果如下:
@RestControllerAdvice @Slf4j public class CustomerExceptionHandler { @ExceptionHandler(AuthException.class) public String ErrorHandler(AuthorizationException e) { log.error("没有通过权限验证!", e); return "没有通过权限验证!"; } @ExceptionHandler(Exception.class) public Result Execption(Exception e) { log.error("未知异常!", e); return Result.error(ResultMsgEnum.SERVER_BUSY.getCode(),ResultMsgEnum.SERVER_BUSY.getMessage()); } }
虽然格式上没有毛病,但是在code、data字段的具体数据上是不友好或不正确的。不处理好这些事情,会严重影响自己在前端妹妹心中的高大形象的,这是决不能容忍的。
以前我们遇到异常时,第一时间想到的应该是try..catch..finnal吧,不过这种方式会导致大量代码重复,维护困难,逻辑臃肿等问题,这不是我们想要的结果。
今天我们要用的全局异常处理方式,用起来是比较简单的。首先新增一个类,增加@RestControllerAdvice
注解,该注解的作用花哥上面已经介绍过,就不再唠叨了。
{ "code": 0, "message": "成功", "data": { "code": 503, "message": "服务器正忙,请稍后再试!", "data": null } }
如果我们有想要拦截的异常类型,就新增一个方法,使用@ExceptionHandler
注解修饰,注解参数为目标异常类型。
例如:controller中接口发生Exception异常时,就会进入到Execption
方法中进行捕获,将杂乱的异常信息,转换成指定格式后交给ResponseAdvice
ResponseAdvice
-Klasse; #🎜🎜# #🎜🎜##🎜🎜##🎜🎜#Implementieren Sie die Schnittstelle ResponseBodyAdvice
und implementieren Sie die Methoden supports
und beforeBodyWrite
; 🎜🎜 ##🎜🎜##🎜🎜#Diese Klasse wird verwendet, um die Rückgabeergebnisse der Schnittstelle im Controller einheitlich zu kapseln. #🎜🎜##🎜🎜##🎜🎜#@RestControllerAdvice public class ResponseAdvice implements ResponseBodyAdvice<Object> { @Autowired private ObjectMapper objectMapper; /** * 是否开启功能 true:开启 */ @Override public boolean supports(MethodParameter methodParameter, Class<? extends HttpMessageConverter<?>> aClass) { return true; } /** * 处理返回结果 */ @Override public Object beforeBodyWrite(Object o, MethodParameter methodParameter, MediaType mediaType, Class<? extends HttpMessageConverter<?>> aClass, ServerHttpRequest serverHttpRequest, ServerHttpResponse serverHttpResponse) { //处理字符串类型数据 if(o instanceof String){ try { return objectMapper.writeValueAsString(Result.success(o)); } catch (JsonProcessingException e) { e.printStackTrace(); } } //返回类型是否已经封装 if(o instanceof Result){ return o; } return Result.success(o); } }#🎜🎜#Wir können es über die Schnittstelle
getUserName
testen und werden feststellen, dass die Ergebnisse mithilfe von Result
zurückgegeben werden > direkt konsistent sind mit. #🎜🎜##🎜🎜# Aufmerksame Freunde müssen jedoch bemerkt haben, dass wir in ResponseAdvice
alle Result.success(o)
verwenden, um die Ergebnisse vom Typ Fehler zu verarbeiten werden nicht verarbeitet. Werfen wir einen Blick darauf: Was ist das Rückgabeergebnis, wenn eine Ausnahme auftritt? Wenn Sie weiterhin den obigen HashMap-Nullzeiger-Ausnahmecode verwenden, lauten die Testergebnisse wie folgt: #🎜🎜#rrreee#🎜🎜#Obwohl das Format kein Problem darstellt, sind die spezifischen Daten im Code und in den Datenfeldern unfreundlich oder falsch. Wenn Sie sich nicht mit diesen Angelegenheiten befassen, wird Ihr großes Image in den Köpfen der Front-End-Schwester ernsthaft beeinträchtigt, was niemals toleriert wird. #🎜🎜##🎜🎜#3.3 Globaler Ausnahmehandler#🎜🎜##🎜🎜#Wenn wir in der Vergangenheit auf eine Ausnahme stießen, dachten wir zuerst an try..catch..finnal, aber diese Methode wird dazu führen Viele Codeduplizierungen, Schwierigkeiten bei der Wartung, aufgeblähte Logik und andere Probleme sind nicht die gewünschten Ergebnisse. #🎜🎜##🎜🎜#Die globale Ausnahmebehandlungsmethode, die wir heute verwenden werden, ist relativ einfach zu verwenden. Fügen Sie zunächst eine neue Klasse und die Annotation @RestControllerAdvice
hinzu. Die Funktion dieser Annotation wurde oben vorgestellt, daher werde ich nicht auf Details eingehen. #🎜🎜#rrreee#🎜🎜#Wenn wir einen Ausnahmetyp haben, den wir abfangen möchten, fügen Sie eine neue Methode hinzu und verwenden Sie die Annotation @ExceptionHandler
, um sie zu ändern. Der Annotationsparameter ist die Zielausnahme Typ. #🎜🎜##🎜🎜#Zum Beispiel: Wenn in der Schnittstelle im Controller eine Ausnahme auftritt, wird die Methode Execption
eingegeben, um sie zu erfassen, die chaotischen Ausnahmeinformationen in das angegebene Format zu konvertieren und weiterzugeben Übergeben Sie es an die Methode ResponseAdvice
, kapseln Sie die Daten in einem einheitlichen Format und geben Sie sie an den Front-End-Partner zurück. #🎜🎜#@RestControllerAdvice @Slf4j public class CustomerExceptionHandler { @ExceptionHandler(AuthException.class) public String ErrorHandler(AuthorizationException e) { log.error("没有通过权限验证!", e); return "没有通过权限验证!"; } @ExceptionHandler(Exception.class) public Result Execption(Exception e) { log.error("未知异常!", e); return Result.error(ResultMsgEnum.SERVER_BUSY.getCode(),ResultMsgEnum.SERVER_BUSY.getMessage()); } }
再次调用接口getUserName
查看返回结果,会发现还是有一些问题,因为我们在CustomerExceptionHandler
中已经将接口返回结果封装成Result
类型,而代码执行到统一结果返回类ResponseAdvice
时,又会结果再次封装,就出现了如下问题。
{ "code": 0, "message": "成功", "data": { "code": 503, "message": "服务器正忙,请稍后再试!", "data": null } }
解决上述问题非常简单,只要在beforeBodyWrite
中增加一条判断即可。
@RestControllerAdvice public class ResponseAdvice implements ResponseBodyAdvice<Object> { @Autowired private ObjectMapper objectMapper; /** * 是否开启功能 true:开启 */ @Override public boolean supports(MethodParameter methodParameter, Class<? extends HttpMessageConverter<?>> aClass) { return true; } /** * 处理返回结果 */ @Override public Object beforeBodyWrite(Object o, MethodParameter methodParameter, MediaType mediaType, Class<? extends HttpMessageConverter<?>> aClass, ServerHttpRequest serverHttpRequest, ServerHttpResponse serverHttpResponse) { //处理字符串类型数据 if(o instanceof String){ try { return objectMapper.writeValueAsString(Result.success(o)); } catch (JsonProcessingException e) { e.printStackTrace(); } } //返回类型是否已经封装 if(o instanceof Result){ return o; } return Result.success(o); } }
Das obige ist der detaillierte Inhalt vonUmgang mit Rückgaben der einheitlichen SpringBoot-Schnittstelle und globalen Ausnahmen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!