@responsebody一般在什么情况下使用，他的好处与坏处

@responsebody表示该方法的返回结果直接写入>

一般在异步获取数据时使用，在使用@RequestMapping后，返回值通常解析为跳转路径，加上@responsebody后返回结果不会被解析为跳转路径，而是直接写入>

好处是：GET模式下，这里使用了@PathVariable绑定输入参数，非常适合Restful风格。因为隐藏了参数与路径的关系，可以提升网站的安全性，静态化页面，降低恶意攻击风险。POST模式下，使用@RequestBody绑定请求对象，Spring会帮你进行协议转换，将Json、Xml协议转换成你需要的对象。@ResponseBody可以标注任何对象，由Srping完成对象——协议的转换。

坏处是：返回之前，若前端编码格式不一致，很容易导致乱码。

最近在看基于SpringBoot的登录逻辑，项目测试时使用Postman模拟表单登录请求，发现，程序总是报415，也就是不支持的类型。网上查了一圈，猜测可能是前后端参数不匹配导致的问题。排查后发现 @RequestBody 有个坑：无法接收表单登录请求。

基于SpringBoot，准备一个路径跳转Controller：

登录界面如下：

登录请求处理：

User 类以及 Result 不重要，这里就不写出来了， User 类只包含 username 和 password 属性。

登录测试：

但是，如果发送的是"application/json"的话：

通过不断debug，可以得到最后路径和方法的映射关系被保存在了 AbstractHandlerMethodMapping 的 mappingLookup 属性中，可以看到映射方法被封装成了 HandlerMethod 类

登录请求发出后会由 DispatcherServlet 类分配进行后续处理的方法：

DispatcherServlet 的 doDispatch 中的

分配处理器。不断debug，最后在 AbstractHandlerMethodMapping 类中的 getHandlerInternal 中看到了分配结果：

最后又回到了 Dispatch ：

正式进入处理流程。

getHandler 方法会返回之前 getHandler 方法返回的处理器。

执行到 RequestMappingHandlerAdapter#invokeHandlerMethod 做一些准备，比如将 HandlerMethod 封装成 ServletInvocableHandlerMethod ：

设置参数、返回值解析器：

调用 invokeAndHandlerMethod 进行处理：

毫无疑问， invokeForRequest 用于执行请求：

先获取并解析参数，再通过 doInvoke 方法执行Controller的自定义逻辑。

@RequestBody 的问题就在解析参数上。

接着，不断debug直到进入 HandlerMethodArgumentResolverComposite 的 getArgumentResolver ，事情逐渐明朗：

参数解析类出现了 RequestResponseBodyMethodProcessor ，而这个类正是用来处理 @RequestBody 和 @ResponseBody 注解的。

下面是 RequestResponseBodyMethodProcessor 抽象父类 AbstractMessageConverterMethodProcessor 的参数处理逻辑。

判断能否进行处理的逻辑( Abstract>

如何使用>

>

以上就是关于@responsebody一般在什么情况下使用，他的好处与坏处全部的内容，包括:@responsebody一般在什么情况下使用，他的好处与坏处、关于@RequestBody的一些分析、重磅来袭：Spring之RequestBody的使用姿势小结等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！

欢迎分享，转载请注明来源：内存溢出

原文地址:https://54852.com/web/9307419.html