当前位置:   article > 正文

ajax返回的数据怎么显示出来_每天用SpringBoot,还不懂RESTful API返回统一数据格式是怎么实现的?

ajax返回数据时,数据直接暴露了

关于 Spring 的全局处理,我有两方面要说:

  1. 统一数据返回格式
  2. 统一异常处理
    为了将两个问题说明清楚,将分两个章节分别说明,本章主要说第一点

有童鞋说,我们项目都做了这种处理,就是在每个 API 都单独工具类将返回值进行封装,但这种不够优雅;我想写最少的代码完成这件事,也许有童鞋说,加几个注解就解决问题了,说的没错,但这篇文章主要是为了说明为什么加了几个注解就解决问题了,目的是希望大家知其所以然

c7177853003a28d49f082b278efb1b91.png

为了更好的说明问题,本文先说明如何实现,然后再详细剖析实现原理(这很关键)

为什么要做统一数据返回格式

前后端分离是当今服务形式的主流,如何设计一个好的 RESTful API ,以及如何让前端小伙伴可以处理标准的 response JSON 数据结构都至关重要,为了让前端有更好的逻辑展示与页面交互处理,每一次 RESTful 请求都应该包含以下几个信息:

名称
描述
status
状态码,标识请求成功与否,如 [1:成功;-1:失败]
errorCode
错误码,给出明确错误码,更好的应对业务异常;请求成功该值可为空
errorMsg
错误消息,与错误码相对应,更具体的描述异常信息
resultBody
返回结果,通常是 Bean 对象对应的 JSON 数据, 通常为了应对不同返回值类型,将其声明为泛型类型

实现

通用返回值类定义

根据上面的描述,用 Java Bean 来体现这个结构就是这样:

  1. @Data
  2. public final class CommonResult<T> {
  3. private int status = 1;
  4. private String errorCode = "";
  5. private String errorMsg = "";
  6. private T resultBody;
  7. public CommonResult() {
  8. }
  9. public CommonResult(T resultBody) {
  10. this.resultBody = resultBody;
  11. }
  12. }

配置

没错,我们需要借助几个关键注解来完成一下相关配置:

  1. @EnableWebMvc
  2. @Configuration
  3. public class UnifiedReturnConfig {
  4. @RestControllerAdvice("com.example.unifiedreturn.api")
  5. static class CommonResultResponseAdvice implements ResponseBodyAdvice<Object>{
  6. @Override
  7. public boolean supports(MethodParameter methodParameter, Class<? extends HttpMessageConverter<?>> aClass) {
  8. return true;
  9. }
  10. @Override
  11. public Object beforeBodyWrite(Object body, MethodParameter methodParameter, MediaType mediaType, Class<? extends HttpMessageConverter<?>> aClass, ServerHttpRequest serverHttpRequest, ServerHttpResponse serverHttpResponse) {
  12. if (body instanceof CommonResult){
  13. return body;
  14. }
  15. return new CommonResult<Object>(body);
  16. }
  17. }
  18. }

到这里就结束了,我们就可以纵情的写任何 RESTful API 了,所有的返回值都会有统一的 JSON 结构

测试

新建 UserController,添加相应的 RESTful API,测试用例写的比较简单,只为了说明返回值的处理

  1. @RestController
  2. @RequestMapping("/users")
  3. public class UserController {
  4. @GetMapping("")
  5. public List<UserVo> getUserList(){
  6. List<UserVo> userVoList = Lists.newArrayListWithCapacity(2);
  7. userVoList.add(UserVo.builder().id(1L).name("日拱一兵").age(18).build());
  8. userVoList.add(UserVo.builder().id(2L).name("tan").age(19).build());
  9. return userVoList;
  10. }
  11. }

打开浏览器输入地址测试: http://localhost:8080/users/ ,我们可以看到返回了 List JSON 数据

6535272657569eaffb33daffac616396.png

继续添加 RESTful API,根据用户 ID 查询用户信息

  1. @GetMapping("/{id}")
  2. public UserVo getUserByName(@PathVariable Long id){
  3. return UserVo.builder().id(1L).name("日拱一兵").age(18).build();
  4. }

打开浏览器输入地址测试: http://localhost:8080/users/1 ,我们可以看到返回了单个 User JSON 数据

0652a97f1651ae67a17b44e09d628ba8.png

添加一个返回值类型为 ResponseEntity 的 API

  1. @GetMapping("/testResponseEntity")
  2. public ResponseEntity getUserByAge(){
  3. return new ResponseEntity(UserVo.builder().id(1L).name("日拱一兵").age(18).build(), HttpStatus.OK);
  4. }

打开浏览器输入地址测试: http://localhost:8080/users/testResponseEntity ,我们可以看到同样返回了单个 User JSON 数据

7d04b7b14efb58d2c2280a5986099852.png

解剖实现过程

我会将关键部分一一说明清楚,断案还需小伙伴自己去案发现场(打开自己的 IDE 查看)

故事要从 @EnableWebMvc 这个注解说起,打开该注解看:

  1. @Retention(RetentionPolicy.RUNTIME)
  2. @Target(ElementType.TYPE)
  3. @Documented
  4. @Import(DelegatingWebMvcConfiguration.class)
  5. public @interface EnableWebMvc {
  6. }

通过 @Import 注解引入了 DelegatingWebMvcConfiguration.class,那来看这个类吧:

  1. @Configuration
  2. public class DelegatingWebMvcConfiguration extends WebMvcConfigurationSupport {
  3. ...
  4. }

@Configuration 注解,你应该很熟悉了,该类的父类 WebMvcConfigurationSupport 中却隐藏着一段关键代码:

  1. @Bean
  2. public RequestMappingHandlerAdapter requestMappingHandlerAdapter() {
  3. RequestMappingHandlerAdapter adapter = createRequestMappingHandlerAdapter();
  4. ...
  5. return adapter;
  6. }

RequestMappingHandlerAdapter 是每一次请求处理的关键,来看该类的定义:

  1. public class RequestMappingHandlerAdapter extends AbstractHandlerMethodAdapter
  2. implements BeanFactoryAware, InitializingBean {
  3. ...
  4. }

该类实现了 InitializingBean 接口,我在 Spring Bean 生命周期之“我从哪里来”? 这篇文章中明确说明了 Spring Bean 初始化的几个关键,其中 InitializingBean 接口的afterPropertiesSet 方法就是关键之一,在 RequestMappingHandlerAdapter 类中同样重写了该方法:

  1. @Override
  2. public void afterPropertiesSet() {
  3. // Do this first, it may add ResponseBody advice beans
  4. initControllerAdviceCache();
  5. if (this.argumentResolvers == null) {
  6. List<HandlerMethodArgumentResolver> resolvers = getDefaultArgumentResolvers();
  7. this.argumentResolvers = new HandlerMethodArgumentResolverComposite().addResolvers(resolvers);
  8. }
  9. if (this.initBinderArgumentResolvers == null) {
  10. List<HandlerMethodArgumentResolver> resolvers = getDefaultInitBinderArgumentResolvers();
  11. this.initBinderArgumentResolvers = new HandlerMethodArgumentResolverComposite().addResolvers(resolvers);
  12. }
  13. if (this.returnValueHandlers == null) {
  14. List<HandlerMethodReturnValueHandler> handlers = getDefaultReturnValueHandlers();
  15. this.returnValueHandlers = new HandlerMethodReturnValueHandlerComposite().addHandlers(handlers);
  16. }
  17. }

该方法内容都非常关键,但我们先来看 initControllerAdviceCache 方法,其他内容后续再单独说明:

  1. private void initControllerAdviceCache() {
  2. ...
  3. if (logger.isInfoEnabled()) {
  4. logger.info("Looking for @ControllerAdvice: " + getApplicationContext());
  5. }
  6. List<ControllerAdviceBean> beans = ControllerAdviceBean.findAnnotatedBeans(getApplicationContext());
  7. AnnotationAwareOrderComparator.sort(beans);
  8. List<Object> requestResponseBodyAdviceBeans = new ArrayList<Object>();
  9. for (ControllerAdviceBean bean : beans) {
  10. ...
  11. if (ResponseBodyAdvice.class.isAssignableFrom(bean.getBeanType())) {
  12. requestResponseBodyAdviceBeans.add(bean);
  13. }
  14. }
  15. }

通过 ControllerAdviceBean 静态方法扫描 ControllerAdvice 注解,可是我们在实现上使用的是 @RestControllerAdvice 注解,打开看该注解:

  1. @Target(ElementType.TYPE)
  2. @Retention(RetentionPolicy.RUNTIME)
  3. @Documented
  4. @ControllerAdvice
  5. @ResponseBody
  6. public @interface RestControllerAdvice {

该注解由 @ControllerAdvice@ResponseBody 标记,就好比你熟悉的 @RestController 注解由 @Controller@ResponseBody 标记是一样的

到这里你已经知道我们用 @RestControllerAdvice 标记的 Bean 是如何被加载到 Spring 上下文的,接下来就要知道是 Spring 是如何使用我们的 bean 以及对返回 body 做处理的

其实在 HttpMessageConverter是如何转换数据的? 这篇文章中已经说明了一部分,希望小伙伴先看这篇文章,下面的部分就会秒懂了,我们在这里做进一步的说明

在 AbstractMessageConverterMethodProcessor 的 writeWithMessageConverters 方法中,有一段核心代码:

  1. if (messageConverter instanceof GenericHttpMessageConverter) {
  2. if (((GenericHttpMessageConverter) messageConverter).canWrite(
  3. declaredType, valueType, selectedMediaType)) {
  4. outputValue = (T) getAdvice().beforeBodyWrite(outputValue, returnType, selectedMediaType,
  5. (Class<? extends HttpMessageConverter<?>>) messageConverter.getClass(),
  6. inputMessage, outputMessage);
  7. ...
  8. return;
  9. }
  10. }

可以看到通过 getAdvice() 调用了 beforeBodyWrite 方法,我们已经接近真相了

  1. protected RequestResponseBodyAdviceChain getAdvice() {
  2. return this.advice;
  3. }

RequestResponseBodyAdviceChain,看名字带有 Chain,很明显用到了「责任链设计模式」,这些内容在 不得不知的责任链设计模式 文章中明确说明过,只不过它传递责任链以循环的方式完成:

  1. class RequestResponseBodyAdviceChain implements RequestBodyAdvice, ResponseBodyAdvice<Object> {
  2. @Override
  3. public Object beforeBodyWrite(Object body, MethodParameter returnType, MediaType contentType,
  4. Class<? extends HttpMessageConverter<?>> converterType,
  5. ServerHttpRequest request, ServerHttpResponse response) {
  6. return processBody(body, returnType, contentType, converterType, request, response);
  7. }
  8. @SuppressWarnings("unchecked")
  9. private <T> Object processBody(Object body, MethodParameter returnType, MediaType contentType,
  10. Class<? extends HttpMessageConverter<?>> converterType,
  11. ServerHttpRequest request, ServerHttpResponse response) {
  12. for (ResponseBodyAdvice<?> advice : getMatchingAdvice(returnType, ResponseBodyAdvice.class)) {
  13. if (advice.supports(returnType, converterType)) {
  14. body = ((ResponseBodyAdvice<T>) advice).beforeBodyWrite((T) body, returnType,
  15. contentType, converterType, request, response);
  16. }
  17. }
  18. return body;
  19. }
  20. }

我们重写的 beforeBodyWrite 方法终究会被调用到,真相就是这样了!!!

其实还没完,你有没有想过,如果我们的 API 方法返回值是 org.springframework.http.ResponseEntity 类型,我们可以指定 HTTP 返回状态码,但是这个返回值会直接放到我们的 beforeBodyWrite 方法的 body 参数中吗?如果这样做很明显是错误的,因为 ResponseEntity 包含很多我们非业务数据在里面,那 Spring 是怎么帮我们处理的呢?

在我们方法取得返回值并且在调用 beforeBodyWrite 方法之前,还要选择 HandlerMethodReturnValueHandler 用于处理不同的 Handler 来处理返回值

在类 HandlerMethodReturnValueHandlerComposite 中的 handleReturnValue 方法中

  1. @Override
  2. public void handleReturnValue(Object returnValue, MethodParameter returnType,
  3. ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception {
  4. HandlerMethodReturnValueHandler handler = selectHandler(returnValue, returnType);
  5. if (handler == null) {
  6. throw new IllegalArgumentException("Unknown return value type: " + returnType.getParameterType().getName());
  7. }
  8. handler.handleReturnValue(returnValue, returnType, mavContainer, webRequest);
  9. }

通过调用 selectHandler 方法来选择合适的 handler,Spring 内置了很多个 Handler,我们来看类图:

fbd54ff903de17a348276f3fc3e16cad.png

HttpEntityMethodProcessor 就是其中之一,它重写了 supportsParameter 方法,支持 HttpEntity 类型,即支持 ResponseEntity 类型:

  1. @Override
  2. public boolean supportsParameter(MethodParameter parameter) {
  3. return (HttpEntity.class == parameter.getParameterType() ||
  4. RequestEntity.class == parameter.getParameterType());
  5. }

所以当我们返回的类型为 ResponseEntity 时,就要通过 HttpEntityMethodProcessor 的 handleReturnValue 方法来处理我们的结果:

  1. @Override
  2. public void handleReturnValue(Object returnValue, MethodParameter returnType,
  3. ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception {
  4. ...
  5. if (responseEntity instanceof ResponseEntity) {
  6. int returnStatus = ((ResponseEntity<?>) responseEntity).getStatusCodeValue();
  7. outputMessage.getServletResponse().setStatus(returnStatus);
  8. if (returnStatus == 200) {
  9. if (SAFE_METHODS.contains(inputMessage.getMethod())
  10. && isResourceNotModified(inputMessage, outputMessage)) {
  11. // Ensure headers are flushed, no body should be written.
  12. outputMessage.flush();
  13. // Skip call to converters, as they may update the body.
  14. return;
  15. }
  16. }
  17. }
  18. // Try even with null body. ResponseBodyAdvice could get involved.
  19. writeWithMessageConverters(responseEntity.getBody(), returnType, inputMessage, outputMessage);
  20. // Ensure headers are flushed even if no body was written.
  21. outputMessage.flush();
  22. }

该方法提取出 responseEntity.getBody(),并传递个 MessageConverter,然后再继续调用 beforeBodyWrite 方法,这才是真相!!!

这是 RESTful API 正常返回内容的情况,下一篇文章,让我们来侦查一下统一异常情况的处理以及实现原理

灵魂追问

  1. 返回值是非 ResponseEntity 类型时,用的是什么 handler?它支持的返回值类型是什么?看过你也许就知道为什么要用 @ResponseBody 注解了
  2. 你有追踪过 DispatchServlet 的整个请求过程吗?

提高效率工具

95a0ec7102ff5c29ce54edfbfe4b6815.png

推荐阅读

  • 只会用 git pull ?有时候你可以尝试更优雅的处理方式
  • 双亲委派模型:大厂高频面试题,轻松搞定
  • 面试还不知道BeanFactory和ApplicationContext的区别?
  • 如何设计好的RESTful API
  • 程序猿为什么要看源码?

--------

欢迎持续关注公众号:「日拱一兵」

- 前沿 Java 技术干货分享

- 高效工具汇总 | 回复「工具」

- 面试问题分析与解答

- 技术资料领取 | 回复「资料」

以读侦探小说思维轻松趣味学习 Java 技术栈相关知识,本着将复杂问题简单化,抽象问题具体化和图形化原则逐步分解技术问题,技术持续更新,请持续关注......

643000c210ad8c42b157e8384008bbcb.png
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小小林熬夜学编程/article/detail/652292
推荐阅读
相关标签
  

闽ICP备14008679号