需求背景
最近有個需求，是對接某個運動APP的Api開放平臺用戶授權(quán)業(yè)務(wù)。文中以兩個API為例：
1、獲取token
場景：用戶在授權(quán)?頁?面點擊授權(quán)后，?頁?面會跳轉(zhuǎn)到合作?方提供的redirect_url，合作?方通過跳轉(zhuǎn)傳回的code換取token，完成認(rèn)證和授權(quán)。
Header附加參數(shù)：Authorization:Basic base64(AppKey:AppSecret) `
注意：Basic后?面必須有一個空格。
2、獲取用戶資料
場景：獲取用戶資料接??于獲取用戶在APP的用戶資料。
Header附加參數(shù)：Authorization:Bearer token
注意：Bearer后?面必須有一個空格。
分析
從上述API資料里面分析得出要對接這兩個API需要設(shè)置不同的Header信息，那么就需要代碼中支持動態(tài)設(shè)置header功能。
API
項目框架
由于項目是使用SpringCloud 集成Feign搭建的基礎(chǔ)框架，并且在項目中已經(jīng)設(shè)計了全局的Header。
通過實現(xiàn)RequestInterceptor接口,完成對所有的Feign請求,設(shè)置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 的代理類在執(zhí)行的時候，會去使用該攔截器，然后注入到 spring 上下文中，這樣就可以在請求的上下文中添加自定義的請求頭。
優(yōu)點：所以自定義自己的攔截器
缺點：操作的是全局的 RequestTemplate，比較難以根據(jù)不同的服務(wù)方提供不同的 header。
方案一：使用Feign官方方案
經(jīng)過分析得出現(xiàn)在的代碼是不支持這次需求，那么項目中既然集成了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);}
通過上面的官方文檔代碼示例發(fā)現(xiàn)不需要那么麻煩，用原生的@Headers 注解就能解決我們的問題了，添加到代碼上。
@Headers 代碼示例
@FeignClient(name = "xxx-feign-service",url = "IP:端口")@Headers({"Authorization: ${token}"}) public interface FeignClient { @RequestMapping(value = "/getToken") String getToken();}
使用{token} 可以傳遞動態(tài)header屬性。
一番折騰后發(fā)現(xiàn)@Headers 沒有生效，在生成的RequestTemplate中，沒有獲取到token值。 然后調(diào)試一下代碼，發(fā)現(xiàn)，ReflectFeign在生成遠程服務(wù)的代理類的時候，會通過 Contract 接口準(zhǔn)備數(shù)據(jù)。 而@Headers 注解沒有生效的原因是：官方的 Contract 沒有生效：
代碼如下：
class FeignClientFactoryBean implements FactoryBean<Object>, InitializingBean, ApplicationContextAware { protected Feign.Builder feign(FeignContext context) { Feign.Builder builder = get(context, Feign.Builder.class) // required values .logger(logger) .encoder(get(context, Encoder.class)) .decoder(get(context, Decoder.class)) .contract(get(context, Contract.class)); ... } }
去翻一下springcloud-openfeign在創(chuàng)建 Feign 相關(guān)類的時候，使用的是容器中注入的 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; }
我們來總結(jié)一下：
1、openfeign本身是支持在方法上使用@Header 注解，來實現(xiàn)自定義header功能。
2、springcloud-openfeign只是集成了openfeign的核心功能，@Headers 注解并沒有被使用。
3、SpringCloud 使用了自己的 SpringMvcContract 來處理請求的相關(guān)資源信息，里面只使用 @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);}
經(jīng)測試SpringCloud 支持@RequestMapping 注解的 header，可以正常獲取頭部信息。
但是問題來了，很多同學(xué)不習(xí)慣在類上直接使用 @RequestMapping 注解，有沒有一個全局管理的地方？也方便代碼維護呢？
方案三：重寫RequestInterceptor的apply方法
上面提到過通過實現(xiàn)RequestInterceptor接口完成對所有的Feign請求，可不可以在FeignClientConfig文件里面統(tǒng)一管理呢？那就需要我們自定義這個類了。具體代碼如下：
@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; }}
注釋：根據(jù)文中開始部分提到的業(yè)務(wù)中有兩個API，并且他們的請求Header信息不一樣，通過重寫RequestInterceptor的apply方法來封裝header值，達到解決動態(tài)參數(shù)的問題（有心的同學(xué)這里的代碼可以更加優(yōu)雅一點兒）。
總結(jié)
通過尋找解決問題的方法發(fā)現(xiàn)SpringMvcContract 是在 parseAndValidatateMetadata 中解決在類上面的 header 的問題，這里也特別提醒一下各位同學(xué)Spring Cloud 并沒有基于Spring MVC 全部注解來做Feign 客戶端注解協(xié)議解析，這個是一個不小的坑。這也導(dǎo)致了最開始沒寫想到在feign接口上使用 @RequestMapping來解決問題。
那么使用@RequestMapping 解決header問題是最簡單也更加原生的方案，通過重寫RequestInterceptor的apply方法來實現(xiàn)可以統(tǒng)一管理頭部信息，方便后續(xù)的維護，兩者各有千秋。
