最近涉及到与先后端的数据对接,按道理来讲没一点压力结果被一前端童鞋带坑里去了(不过也是好久没写过这种先后端分离进行联调的事情了,若是是一我的全套弄的话就不会出现下面问题)。前端
进入正文,跟前端进行数据联调时,别人联调都正常,到联调个人接口(进行数据获取)就出现了问题。web
下面进行异常场景还原(后端环境:Spring MVC4.0.5):spring
一、前端访问我这边的接口抛出错误码:405 Method not allowed 。当时就感受奇怪,我本身用postman都能调通啊,为何你那边不能容许访问呢。看到这个错误码,因而我就抛出两个问题给他:json
而后他坚决果断的说都是。
二、因而我看下后端请求的日志,SpringMVC日志提示:“[org.springframework.web.servlet.PageNotFound] >>> Request method 'POST' not supported” 。 后端
提示这个错误,我就纳闷了。条件反射让我想起是否是在@RequestMapping中Method 没有指定为post? 其实我指定了post方法的,这个确定排除了。缓存
@RequestMapping(value = "/home/test", method = RequestMethod.POST) @ResponseBody public Object test(@RequestBody UserEntity userEntity) { return "1234"; }
难道真的是我后端的问题?查了网上不少问题一堆不靠谱:(,一直沉迷于Request method 'POST' not supported这个信息没法自拔,难道这配置不支持post方法?。因而就尝试了如下手段:mvc
a、ResourceHttpRequestHandler在springMVC配置文件配置强制支持post方法。可想而知,ResourceHttpRequestHandler针对静态资源的获取及其缓存设置。很明显不符合场景,试了也是白试。若是你这种场景请参考这里获取对你有帮助:https://stackoverflow.com/questions/15588001/spring-not-accept-post-request-under-mvcresources-how-to-fix-that。app
b、尝试将RequestMapping中请求的方法改为get,前端也用get请求,并无用。前后端分离
三、尝试了上面方法后无果,有位前辈说不妨你跟踪下SpringMVC中日志代码。post
第一步:查看PageNotFound是否存在对应的类(这一步其实一出现我就查看是没有的),怎么验证它是否存在呢?很简单:在代码中输入它看是否有对应的引用包。
第二步:第一步最直接的入口失败,因而想到了SpringMVC的核心Servlet:DispatcherServlet, 而它的核心方法则是:doDispatch,因而在方法中进行断点调试找到出错缘由。通过调试后,终于发现问题所在,发如今解析json是实体的属性出错,以下图:
上述案例是说不能解析namqe这个属性,而我UserEntity对象中的属性是name,因此解析类就抛出异常(至于在哪一步解析出错,这就不一一说了)。
通过上面一步一步的探索终于找到问题的所在:原来是前端童鞋传json的时候,把参数名称弄错了。
四、拓展
虽然问题解决了,可是为啥Spring MVC 为啥抛出那样的日志,而不是具体的错误信息呢?若是是具体的错误信息那不简单明了嘛,也不至于花了这么时间去定位问题所在。因而继续调试看看这个错误信息为何被转换了?看上面图的971行,最终结果都会进入到这个方法processDispatchResult,而它的第一步就是检测是否有异常,若是有异常则先处理异常:
里面流程也不一一显示了,直接跳到具体解析异常的类:DefaultHandlerExceptionResolver,咱们看看这个类中有什么又是怎么处理异常的。
看到上图就应该想到以前提示的日志为何有[org.springframework.web.servlet.PageNotFound],而找不到对应的类了吧,由于它只是一个日志的Event_Name。
继续跟踪:最终它是走入了HttpMessageNotReadableException类,表示读取信息错误。
继续进入handleHttpMessageNotReadable方法,看到这里就知道结果了,它把原来的错误信息给修改并返回了。
另外这里不是真的返回信息,上面错误信息返回以后还会再次进入DispatcherServlet类从新又走了一遍,因此错误信息又从新判断一次最终进入了下面这个方法,真正的输入日志的地方在这:
因此这个是Spring MVC 4.0.5.RELEASE版本的问题,升级到4.2.0以上就不会抛出这个问题,它会识别能识别的参数继续运行,不会抛出错误。
针对这种405错误,总结一下几点:
一、首先第一个须要确认请求方法类型是否一致?
二、请求数据类型 和 接收的数据类型是否一致?
三、请求参数是否正确?
以上都正确的话,而后在具体问题具体分析,一步一步跟踪才是最有效的。
赶上问题要冷静,盲目从医只会浪费时间,须要对症下药,一步一步来。