需求背景
最近有个需求,是对接某个运动APP的Api开放平台用户授权业务。文中以两个API为例:
1、获取token
场景:用户在授权⻚页⾯面点击授权后,⻚页⾯面会跳转到合作⽅方提供的redirect_url,合作⽅方通过跳转传回的code换取token,完成认证和授权。
Header附加参数:Authorization:Basic base64(AppKey:AppSecret) `
注意:Basic后⾯面必须有一个空格。
2、获取用户资料
场景:获取用户资料接⼝⽤于获取用户在APP的用户资料。
Header附加参数:Authorization:Bearer token
注意:Bearer后⾯面必须有一个空格。
分析
从上述API资料里面分析得出要对接这两个API需要设置不同的Header信息,那么就需要代码中支持动态设置header功能。
API
项目框架
由于项目是使用SpringCloud 集成Feign搭建的基础框架,并且在项目中已经设计了全局的Header。
通过实现RequestInterceptor接口,完成对所有的Feign请求,设置Header代码如下:
@Configurationpublic class FeignClientConfig implements RequestInterceptor { @Value("${token}") private String token; @Override public void apply(RequestTemplate template) { template.header("token", token); } /*打印feign请求日志级别*/ @Bean public Logger.Level level() { return Logger.Level.FULL; }}
原理:@FeignClient 的代理类在执行的时候,会去使用该拦截器,然后注入到 spring 上下文中,这样就可以在请求的上下文中添加自定义的请求头。
优点:所以自定义自己的拦截器
缺点:操作的是全局的 RequestTemplate,比较难以根据不同的服务方提供不同的 header。
方案一:使用Feign官方方案
经过分析得出现在的代码是不支持这次需求,那么项目中既然集成了OpenFeign,可以从这里入手看看官方是如何解决的。
OpenFeign源码地址:https://github.com/OpenFeign/feign
// openfeign 官方文档代码示例public interface ContentService { @RequestLine("GET /api/documents/{contentType}") @Headers("Accept: {contentType}") String getDocumentByType(@Param("contentType") String type);}
通过上面的官方文档代码示例发现不需要那么麻烦,用原生的@Headers 注解就能解决我们的问题了,添加到代码上。
@Headers 代码示例
@FeignClient(name = "xxx-feign-service",url = "IP:端口")@Headers({"Authorization: ${token}"}) public interface FeignClient { @RequestMapping(value = "/getToken") String getToken();}
使用{token} 可以传递动态header属性。
一番折腾后发现@Headers 没有生效,在生成的RequestTemplate中,没有获取到token值。 然后调试一下代码,发现,ReflectFeign在生成远程服务的代理类的时候,会通过 Contract 接口准备数据。 而@Headers 注解没有生效的原因是:官方的 Contract 没有生效:
代码如下:
class FeignClientFactoryBean implements FactoryBean
去翻一下springcloud-openfeign在创建 Feign 相关类的时候,使用的是容器中注入的 Contract代码如下:
@Bean@ConditionalOnMissingBeanpublic Contract feignContract(ConversionService feignConversionService) { return new SpringMvcContract(this.parameterProcessors, feignConversionService);} public class SpringMvcContract extends Contract.BaseContract implements ResourceLoaderAware { @Override public MethodMetadata parseAndValidateMetadata(Class> targetType, Method method) { .... // 注意这里,它只取了 RequestMapping 注解 RequestMapping classAnnotation = findMergedAnnotation(targetType, RequestMapping.class); .... parseHeaders(md, method, classAnnotation); } return md; }
我们来总结一下:
1、openfeign本身是支持在方法上使用@Header 注解,来实现自定义header功能。
2、springcloud-openfeign只是集成了openfeign的核心功能,@Headers 注解并没有被使用。
3、SpringCloud 使用了自己的 SpringMvcContract 来处理请求的相关资源信息,里面只使用 @RequestMapping 注解。
也就是被阉割了呗~~~~
方案二:使用 @RequestMapping的 headers 属性
上面提到了第3点可以使用 **@RequestMapping **注解中的headers属性来解决,来试一下。
@FeignClient(name = "xxx-feign-service",url = "127.0.0.1:8080")public interface FeignClient { @RequestMapping(value = "/getToken") String getToken(@Param("token") String token);}
经测试SpringCloud 支持@RequestMapping 注解的 header,可以正常获取头部信息。
但是问题来了,很多同学不习惯在类上直接使用 @RequestMapping 注解,有没有一个全局管理的地方?也方便代码维护呢?
方案三:重写RequestInterceptor的apply方法
上面提到过通过实现RequestInterceptor接口完成对所有的Feign请求,可不可以在FeignClientConfig文件里面统一管理呢?那就需要我们自定义这个类了。具体代码如下:
@Configuration@Datapublic class FeignClientConfig implements RequestInterceptor { @Value("${appKey}") private String appkey; @Value("${appSecret}") private String appSecret; private String token; @Bean public RequestInterceptor RequestInterceptor() { return new RequestInterceptor() { @Override public void apply(RequestTemplate template) { String text = appkey+":"+appSecret; String authorization = ""; if(StringUtils.isBlank(token)){ authorization="Basic "+ StringUtil.encode(text); }else{ authorization="Bearer "+ token; } template.header("Authorization", authorization); } }; } /*打印feign请求日志级别*/ @Bean public Logger.Level level() { return Logger.Level.FULL; }}
注释:根据文中开始部分提到的业务中有两个API,并且他们的请求Header信息不一样,通过重写RequestInterceptor的apply方法来封装header值,达到解决动态参数的问题(有心的同学这里的代码可以更加优雅一点儿)。
总结
通过寻找解决问题的方法发现SpringMvcContract 是在 parseAndValidatateMetadata 中解决在类上面的 header 的问题,这里也特别提醒一下各位同学Spring Cloud 并没有基于Spring MVC 全部注解来做Feign 客户端注解协议解析,这个是一个不小的坑。这也导致了最开始没写想到在feign接口上使用 @RequestMapping来解决问题。
那么使用@RequestMapping 解决header问题是最简单也更加原生的方案,通过重写RequestInterceptor的apply方法来实现可以统一管理头部信息,方便后续的维护,两者各有千秋。