Spring Boot使用RestTemplate消费REST服务的几个问题记录
Jeff Wong---原文地址
我们可以通过Spring Boot快速开发REST接口，同时也可能需要在实现接口的过程中，通过Spring Boot调用内外部REST接口完成业务逻辑。
在Spring Boot中，调用REST Api常见的一般主要有两种方式，通过自带的RestTemplate或者自己开发http客户端工具实现服务调用。
RestTemplate基本功能非常强大，不过某些特殊场景，我们可能还是更习惯用自己封装的工具类，比如上传文件至分布式文件系统、处理带证书的https请求等。
本文以RestTemplate来举例，记录几个使用RestTemplate调用接口过程中发现的问题和解决方案。
一、RestTemplate简介
1、什么是RestTemplate
我们自己封装的HttpClient，通常都会有一些模板代码，比如建立连接，构造请求头和请求体，然后根据响应，解析响应信息，最后关闭连接。
RestTemplate是Spring中对HttpClient的再次封装，简化了发起HTTP请求以及处理响应的过程，抽象层级更高，减少消费者的模板代码，使冗余代码更少。
其实仔细想想Spring Boot下的很多XXXTemplate类，它们也提供各种模板方法，只不过抽象的层次更高，隐藏了更多细节而已。
顺便提一下，Spring Cloud有一个声明式服务调用Feign,是基于Netflix Feign实现的，整合了Spring Cloud Ribbon与 Spring Cloud Hystrix，并且实现了声明式的Web服务客户端定义方式。
本质上Feign是在RestTemplate的基础上对其再次封装，由它来帮助我们定义和实现依赖服务接口的定义。
2、RestTemplate常见方法
常见的REST服务有很多种请求方式，如GET,POST,PUT,DELETE,HEAD,OPTIONS等。RestTemplate实现了最常见的方式，用的最多的就是Get和Post了，调用API可参考源码，这里列举几个方法定义（GET、POST、DELETE）：
methods
同时要注意两个较为“灵活”的方法exchange和execute。
RestTemplate暴露的exchange与其它接口的不同：
（1）允许调用者指定HTTP请求的方法（GET,POST,DELETE等）
（2）可以在请求中增加body以及头信息，其内容通过参数‘HttpEntity<?>requestEntity’描述
（3）exchange支持‘含参数的类型’（即泛型类）作为返回类型，该特性通过‘ParameterizedTypeReference<T>responseType’描述。
RestTemplate所有的GET,POST等等方法，最终调用的都是execute方法。excute方法的内部实现是将String格式的URI转成了java.net.URI，之后调用了doExecute方法，doExecute方法的实现如下：
doExecute
doExecute方法封装了模板方法，比如创建连接、处理请求和应答，关闭连接等。
多数人看到这里，估计都会觉得封装一个RestClient不过如此吧？
3、简单调用
以一个POST调用为例：
GoodsServiceClient
demo里直接RestTemplate.postForObject方法调用，反序列化实体转换这些RestTemplate内部封装搞定。
二、问题汇总
1、no suitable HttpMessageConverter found for request type异常
这个问题通常会出现在postForObject中传入对象进行调用的时候。
分析RestTemplate源码，在HttpEntityRequestCallback类的doWithRequest方法中，如果messageConverters（这个字段后面会继续提及）列表字段循环处理的过程中没有满足return跳出的逻辑（也就是没有匹配的HttpMessageConverter），则抛出上述异常：
HttpEntityRequestCallback.doWithRequest
最简单的解决方案是，可以通过包装http请求头，并将请求对象序列化成字符串的形式传参，参考示例代码如下：
postForObject
如果我们还想直接返回对象，直接反序列化返回的字符串即可：
postForObject
其中，序列化和反序列化工具比较多，常用的比如fastjson、jackson和gson。
2、no suitable HttpMessageConverter found for response type异常
和发起请求发生异常一样，处理应答的时候也会有问题。
StackOverflow上有人问过相同的问题，根本原因是HTTP消息转换器HttpMessageConverter缺少MIME Type，也就是说HTTP在把输出结果传送到客户端的时候，客户端必须启动适当的应用程序来处理这个输出文档，这可以通过多种MIME（多功能网际邮件扩充协议）Type来完成。
对于服务端应答，很多HttpMessageConverter默认支持的媒体类型（MIMEType）都不同。StringHttpMessageConverter默认支持的则是MediaType.TEXT_PLAIN，SourceHttpMessageConverter默认支持的则是MediaType.TEXT_XML，FormHttpMessageConverter默认支持的是MediaType.APPLICATION_FORM_URLENCODED和MediaType.MULTIPART_FORM_DATA，在REST服务中，我们用到的最多的还是MappingJackson2HttpMessageConverter，这是一个比较通用的转化器（继承自GenericHttpMessageConverter接口），根据分析，它默认支持的MIMEType为MediaType.APPLICATION_JSON：
MappingJackson2HttpMessageConverter
但是有些应用接口默认的应答MIMEType不是application/json，比如我们调用一个外部天气预报接口，如果使用RestTemplate的默认配置，直接返回一个字符串应答是没有问题的：
String url = "http://wthrcdn.etouch.cn/weather_mini?city=上海"; String result = restTemplate.getForObject(url, String.class); ClientWeatherResultVO vo = SerializeUtil.DeSerialize(result, ClientWeatherResultVO.class);
但是，如果我们想直接返回一个实体对象：
String url = "http://wthrcdn.etouch.cn/weather_mini?city=上海"; ClientWeatherResultVO weatherResultVO = restTemplate.getForObject(url, ClientWeatherResultVO.class);
则直接报异常：
Could not extract response: no suitable HttpMessageConverter found for response type [class ]
and content type [application/octet-stream]
很多人碰到过这个问题，首次碰到估计大多都比较懵吧，很多接口都是json或者xml或者plain text格式返回的，什么是application/octet-stream？
查看RestTemplate源代码，一路跟踪下去会发现HttpMessageConverterExtractor类的extractData方法有个解析应答及反序列化逻辑，如果不成功，抛出的异常信息和上述一致：
HttpMessageConverterExtractor.extractData
StackOverflow上的解决的示例代码可以接受，但是并不准确，常见的MIMEType都应该加进去，贴一下我认为正确的代码：
RestTemplateConfig
看到上面的代码，再对比一下RestTemplate内部实现，就知道我参考了RestTemplate的源码，有洁癖的人可能会说这一坨代码有点啰嗦，上面那一堆static final的变量和messageConverters填充数据方法，暴露了RestTemplate的实现，如果RestTemplate修改了，这里也要改，非常不友好，而且看上去一点也不OO。
经过分析，RestTemplateBuilder.build()构造了RestTemplate对象，只要将内部MappingJackson2HttpMessageConverter修改一下支持的MediaType即可，RestTemplate的messageConverters字段虽然是private final的，我们依然可以通过反射修改之，改进后的代码如下：
RestTemplateConfig
除了一个messageConverters字段，看上去我们不再关心RestTemplate那些外部依赖包和内部构造过程，果然干净简洁好维护了很多。
3、乱码问题
这个也是一个非常经典的问题。解决方案非常简单，找到HttpMessageConverter，看看默认支持的Charset。AbstractJackson2HttpMessageConverter是很多HttpMessageConverter的基类，默认编码为UTF-8：
AbstractJackson2HttpMessageConverter
而StringHttpMessageConverter比较特殊，有人反馈过发生乱码问题由它默认支持的编码ISO-8859-1引起：
StringHttpMessageConverter
如果在使用过程中发生乱码，我们可以通过方法设置HttpMessageConverter支持的编码，常用的有UTF-8、GBK等。
4、反序列化异常
这是开发过程中容易碰到的又一个问题。因为Java的开源框架和工具类非常之多，而且版本更迭频繁，所以经常发生一些意想不到的坑。
以joda time为例，joda time是流行的java时间和日期框架，但是如果你的接口对外暴露joda time的类型，比如DateTime，那么接口调用方（同构和异构系统）可能会碰到序列化难题，反序列化时甚至直接抛出如下异常：
org.springframework.http.converter.HttpMessageConversionException: Type definition error: [simple type, class org.joda.time.Chronology]; nested exception is com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Cannot construct instance of `org.joda.time.Chronology` (no Creators, like default construct, exist): abstract types either need to be mapped to concrete types, have custom deserializer, or contain additional type information
at [Source: (PushbackInputStream);
我在前厂就碰到过，可以参考这里，后来为了调用方便，改回直接暴露Java的Date类型。
当然解决的方案不止这一种，可以使用jackson支持自定义类的序列化和反序列化的方式。在精度要求不是很高的系统里，实现简单的DateTime自定义序列化：
DateTimeSerializer
以及DateTime反序列化：
DatetimeDeserializer
最后可以在RestTemplateConfig类中对常见调用问题进行汇总处理，可以参考如下：
RestTemplateConfig
目前良好地解决了RestTemplate常见调用问题，而且不需要你写RestTemplate帮助工具类了。
上面列举的这些常见问题，其实.NET下面也有，有兴趣大家可以搜索一下微软的HttpClient常见使用问题，用过的人都深有体会。更不用提RestSharp这个开源类库，几年前用的过程中发现了非常多的Bug，到现在还有一个反序列化数组的问题困扰着我们，我只好自己造个简单轮子特殊处理，给我最深刻的经验就是，很多看上去简单的功能，真的碰到了依然会花掉不少的时间去排查和解决，甚至要翻看源码。所以，我们写代码要认识到，越是通用的工具，越需要考虑到特例，可能你需要花80%以上的精力去处理20%的特殊情况，这估计也是满足常见的二八定律吧。
参考：
https://stackoverflow.com/questions/10579122/resttemplate-no-suitable-httpmessageconverter
http://www.cnblogs.com/rollenholt/p/3934649.html
http://forum.spring.io/forum/spring-projects/android/126794-no-suitable-httpmessageconverter-found
共同学习，写下你的评论
评论加载中...
作者其他优质文章
