前言:
通过实践而发现真理,又通过实践而证实真理和发展真理。从感性认识而能动地发展到理性认识,又从理性认识而能动地指导革命实践,改造主观世界和客观世界。实践、认识、再实践、再认识,这种形式,循环往复以至无穷,而实践和认识之每一循环的内容,都比较地进到了高一级的程度。
简单回顾
在那之前,完成了最简单的全局响应和全局异常响应
现在进入到挖深度的环节
简单了解了统一响应的起源------前后端分离,提高两者交流
简单了解了统一响应实体的来源------http响应机制,提炼出三个统一属性(状态码,信息,数据)
正片
javapublic class ApiResultUnit { /** * 禁止实例化,避免不必要的报错 */ private ApiResultUnit(){ } /** * 请求成功------标准响应 * * @param data 响应数据 * @param <T> 响应类型 * @return ApiResult实体 */ public static <T> ApiResult<T> success(T data){ return new ApiResult<>(ApiResult.OK,"操作成功",data); } /** * 请求成功------自定义信息响应 * * @param data 响应数据 * @param message 响应信息 * @param <T> 响应类型 * @return ApiResult实体 */ public static <T> ApiResult<T> success(String message,T data){ return new ApiResult<>(ApiResult.OK,message,data); } /** *请求成功------业务异常响应 * * @param code 状态码 * @param message 响应信息 * @param <T> 响应类型 * @return ApiResult实体 */ public static <T> ApiResult<T> error(int code,String message){ return new ApiResult<>(code,message,null); } }
作者这里进过实践,进行了优化
去掉了完全自定义成功响应,去掉了默认失败响应,当然这个默认失败响应正确的描述应该是系统异常,也就是http状态码里的500错误,我们在全局异常中和设置,所以就不在工具类这里设置了
为什么要用工具类呢?
给大伙看一个案例
java@GetMapping("/findById") public ApiResult<UserEntity> findById(Long id) { UserEntity byId = userService.findById(id); if (byId != null) { return new ApiResult<>(200, "操作成功", byId); } return new ApiResult<>(430,"未查询用户",null); }
你第一眼,你能判断出哪个是成功吗?
啊对对对
我知道,操作成功

这样呢
我知道,看状态码,去你打野的,别看
为了更直观,更明了,区分成功和失败,减少代码的重复性
让你写一百个(200,"操作成功",null)也是很无味的
我们只要调用
/** * 请求成功——标准响应 * * @param data 响应数据 * @param <T> 响应类型 * @return ApiResult实体 */ public static <T> ApiResult<T> success(T data){ return new ApiResult<>(ApiResult.OK,"操作成功",data); }
传入data即可
总结一下工具类的作用:减少代码重复,增加代码的可读性,你一看,success(成功),这就是成功,而不是通过状态码200,信息判断"操作成功"