WebApiClient 中动态路由的实现与使用 - 元视角

元视角

飞鸿踏雪 · 2020-04-02 · via 元视角

博主曾经在「声明式 RESTful 客户端 WebApiClient 在项目中的应用」这篇博客中，介绍过.NET 平台下的“Retrofit”——WebApiClient，它是一种声明式的 RESTful 客户端，通过动态代理来生成 Http 调用过程代码，而调用方只需要定义一个接口，并使用相关“注解”对接口进行修饰即可，类似的实现还有Refit，是一种比 HttpWebRequest、HttpClient 和 RestSharp 更为优雅的接口调用方式。在今天这篇博客中，我想聊聊 WebApiClient 中动态路由的实现与使用。

一个典型的 WebApiClient 使用流程如下，首先定义一个接口，并使用“注解”对接口进行修饰：

public interface ISinoiovApiClient : IHttpApiClient
{
    /// <summary>
    /// 运单取消接口
    /// </summary>
    /// <returns></returns>
    [HttpPost("/yl/api/waybill/cancel")]
    [AuthorizeFilter]
    [LoggingFilter]
    [JsonReturn]
    ITask<BaseApiResult<object>> CancelShipment([JsonContent]BaseShipmentDto shipment);
}

接下来，调用就变得非常简单：

var config = new HttpApiConfig () { HttpHost = new Uri (baseUrl) };
using (var client = HttpApiClient.Create<ISinoiovApiClient> (config)) 
{
    var result = await client.CancelShipment (new BaseShipmentDto () { });
    //TODO：TODO的意思就是永远都不做
}

有多简单呢？简单到调用的时候我们只需要给一个 baseUrl 就可以了！然而，如果你真这么想的话，就太天真了！虽然现在是一个遍地都是微服务和容器的时代，可是因为 RESTful 风格本身的约束力并不强，实际使用中难免会出现以下情况：

//测试环境
http://your-domain.com/test/api/waybill/cancel
//正式环境
http://your-domain.com/prod/api/waybill/cancel

是的，你猜对了，实际运作过程中，测试环境和正式环境不单单会使用不同的域名，可能还会使用不同的路由，虽然，理论上两个环境的程序应该完全一样，应该使用相同的路由。这样子就让我们有一点尴尬，因为我们的路由是写在特性(Attribute)里的，这玩意儿的实例化是附着在对应的类上面的，并且在整个运行时期间是不允许修改的。所谓**“兵来将挡水来土掩”**，接下来，我们来考虑如何解决这个问题。

使用[Uri]

第一种思路是给接口加一个 Url 参数，此时，调整接口方法声明如下：

    /// <summary>
    /// 运单取消接口
    /// </summary>
    /// <returns></returns>
    [HttpPost]
    [AuthorizeFilter]
    [LoggingFilter]
    [JsonReturn]
    ITask<BaseApiResult<object>> CancelShipment([Uri]string url, [JsonContent]BaseShipmentDto shipment);

这种方式可以解决问题，可我使用 WebApiClient 的原因之一，就是我不喜欢在客户端(调用方)维护这些地址。作为一个 ApiCaller，在微服务架构流行以来，接口越来越多，逐渐呈现出爆炸式增加的趋势。当我作为一个后端工程师的时候，编写接口是件非常惬意的事情。可当我为了"全栈工程师"的虚名，去做一个面无表情的 ApiCaller 的时候，我是不情愿去配置这些 Url 的，有本事你把配置中心搭起来啊！所以，道理我都懂，But，我拒绝！

使用{foobar}

第二种思路是同样是给接口增加一个片段参数，此时，调整接口方法声明如下:

    /// <summary>
    /// 运单取消接口
    /// </summary>
    /// <returns></returns>
    [HttpPost('/{prefix}/api/waybill/cancel)]
    [AuthorizeFilter]
    [LoggingFilter]
    [JsonReturn]
    ITask<BaseApiResult<object>> CancelShipment([JsonContent]BaseShipmentDto shipment, string prefix = "yl");

这种方式和第一种方式原理一致，无非是需要配置的参数从多个变成一个。我个人更喜欢这种方式，为什么呢？可能我认为专业的 Api 接口会有版本的概念，类似于：

//版本号路由
/api/v2.0/abc/xyz
//查询参数路由
/api/abc/xyz?v=2.0

这样，我们就在无形中解决了一类问题，对于第二种形式，版本号以查询参数的方式出现，我们选择在过滤器中AddUrlQuery()或者使用[PathQuery]来解决。如果让我选择，我一定会选择这种方式，因为它更优雅一点吗？不，因为我懒，写程序的终究目的就是为了不写代码，就好像一个程序试图去杀死它自己的进程。

使用服务发现

第三种思路，我承认有一点赌的成份，你猜对接客户的接口的时候，会不会提供服务发现这套基础设施给你？可如果在自己的项目里有服务发现，还需要再配置每个服务的 Url 吗？这样想是不是觉得还不错，的确，我们在微服务架构里引入 WebApiClient 这种类 Retrofit 的库，本质上还是为了弱化服务的界限感，如果我调用一个服务和调用本地方法的体验一样，那么，这是什么呢？不用怀疑，这就是 RPC(大雾)。这里，我实现了一个简单的示例：

//通过Consul获取可用地址
var services = await _consul.Health.Service("SinoiovApi", string.Empty, true);
var serviceUrls = services.Response.Select(s => $"{s.Service.Address}:{s.Service.Port}").ToList();
serviceUrl = serviceUrls[new Random().Next(0, serviceUrls.Count - 1)];
//今天的你我，怎样重复昨天的故事
var config = new HttpApiConfig () { HttpHost = new Uri (serviceUrl) };
using (var client = HttpApiClient.Create<ISinoiovApiClient> (config)) 
{
    var result = await client.CancelShipment (new BaseShipmentDto () { });
    //TODO：TODO的意思就是永远都不做
}

当然，我说了这有赌的成份，前提是这些服务在 Consul 中提前注册，这一点相信大家都知道啦！WebApiClient 的作者提供了类似扩展:WebApiClient.Extensions.DiscoveryClient，该扩展基于Steeltoe打造，感兴趣的朋友，可以前去了解一下。

此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。原文来自 — 版权归原作者所有。

推荐订阅源

元视角

使用[Uri]

使用{foobar}

使用服务发现