ASP.NET Core 2.1 中的 HttpClientFactory (Part 3) 使用Handler实现传出请求中间件
原文:https://www.stevejgordon.co.uk/httpclientfactory-aspnetcore-outgoing-request-middleware-pipeline-delegatinghandlers
发表于:2018年4月
先前的系列文章中我介绍了一些核心概念,并且展示了asp.net core 2.1中新的ihttpclientfactory的一些示例。前面两个帖子开始已经有一段时间了,我想通过讨论带有handler的“传出请求中间件”的概念来继续本系列。
delegatinghandlers
首先我们要知道,这部分功能中涉及的许多部件已经存在了很长时间。httpclientfactory通过更加灵活和清晰的api简化了这些部件的使用。
在发起http请求时,您可能希望通过给定的httpclient将所有请求实现cross cutting concerns(aop基于切面的设计)。诸如处理重试失败的信息,记录诊断信息或者实现一个缓存层以减少http的调用次数。
对于熟悉asp.net core的人,您也可能熟悉中间件概念。 delegatinghandlers提供了几乎相同的概念,但相反,是在发出传出请求时。
您可以将一组处理程序(handlers)定义为管道,在发送之前,它们(handlers)会处理传出的http请求。这些处理程序可以以编程方式修改标头,检查请求的主体或者记录有关请求的一些信息。
httprequestmessage在它到达最终内部处理程序(final inner handler)之前依次流经每个处理程序。这个处理程序实际上将通过网络分派http请求。这个内部处理程序也将是第一个接收响应的人。此时,响应以相反的顺序通过处理程序的回切线传回。同样,每个处理程序都可以根据需要检查,修改或使用响应。例如,对于某些请求路径,您可能希望应用返回数据的缓存。
图中您可以看到可视化的管道
与asp.net core中间件非常相似,处理程序也可以使流程短路来立即返回响应。这在强制执行某些规则时比较有用。例如,您可以创建一个处理程序,检查传出请求的中是否存在api密钥头(key header)。如果缺少这个,程序将不会把请求传递给下一个处理程序(避免实际的http调用),程序会生成一个失败响应返回给调用者。
在使用ihttpclientfactory之前,您需要将处理程序实例(可以是多个)传递到httpclient实例的构造函数中。然后,httpclient将通过这些处理程序处理传出请求。
我们可以为不同的“命名化客户端”或“类型化客户端”使用不同的处理程序配置。
创建处理程序(creating a handler)
我们先定义两个handler,为了保持代码简单,它们的功能不会特别逼真,仅为了展示关键概念。后面的例子中有一些方法可以实现类似的结果,而无需编写我们自己的处理程序。
要创建一个处理程序,我们可以简单地创建一个继承于delegatinghandler抽象类的类。我们可以覆盖sendasync方法来添加我们自己的功能。
public class timinghandler : delegatinghandler { private readonly ilogger<timinghandler> _logger; public timinghandler(ilogger<timinghandler> logger) { _logger = logger; } protected override async task<httpresponsemessage> sendasync(httprequestmessage request, cancellationtoken cancellationtoken) { var sw = stopwatch.startnew(); _logger.loginformation("starting request"); var response = await base.sendasync(request, cancellationtoken); _logger.loginformation($"finished request in {sw.elapsedmilliseconds}ms"); return response; } }
我们的例子展示的是传出请求。在发起请求前,stopwatch开始执行,接下来异步执行基类的sendasync方法并返回一个httpresponsemessage。
为了让事情变得有趣,让我们创建第二个处理程序。它将检查是否存在特定的header,如果没有,则返回立即响应,通过“短路”来避免不必要的http调用。
public class validateheaderhandler : delegatinghandler { protected override async task<httpresponsemessage> sendasync(httprequestmessage request, cancellationtoken cancellationtoken) { if (!request.headers.contains("x-api-key")) { return new httpresponsemessage(httpstatuscode.badrequest) { content = new stringcontent("you must supply an api key header called x-api-key") }; } return await base.sendasync(request, cancellationtoken); } }
注册处理程序(registering handlers)
现在我们准备好了处理程序,最后一步是使用依赖注入容器注册它们并定义一个客户端。我们在startup类中的configureservices方法做这些工作。
public void configureservices(iservicecollection services) { services.addtransient<timinghandler>(); services.addtransient<validateheaderhandler>(); services.addhttpclient("github", c => { c.baseaddress = new uri("https://api.github.com/"); c.defaultrequestheaders.add("accept", "application/vnd.github.v3+json"); c.defaultrequestheaders.add("user-agent", "httpclientfactory-sample"); }) .addhttpmessagehandler<timinghandler>() // this handler is on the outside and executes first on the way out and last on the way in. .addhttpmessagehandler<validateheaderhandler>(); // this handler is on the inside, closest to the request. }
前两行将处理程序分别注册到service collection,并且使用 transient,以便在每次创建新的httpclient时都会提供一个新实例。
接下来定义一个客户端。为方便演示,我们使用命名化客户端(named client)。在这个例子中,addhttpclient方法返回一个ihttpclientbuilder。我们再调用ihttpclientbuilder的泛型扩展方法addhttpmessagehandler,此方法将处理程序的类型作为泛型参数。
注册顺序很重要。我们首先注册最外层的处理程序(timinghandler)。该处理程序将第一个检查请求,并最后一个检查响应。在我们的例子中,我们希望timing handler能够记录整个请求流(request flow)的完整时间,包括任何内部处理程序所用时间,因此我们首先添加它。接着,我们再次调用addhttpmessagehandler,注册validateheaderhandler。它是内部httpclienthandler传递请求之前最后的自定义处理程序。
至此,我们在“github”客户端(named client)上定义了一个传出中间件管道。当发起请求时,首先经过timinghandler,然后是validateheaderhandler。如果请求中包含指定的header,则它将被允发送到请求中的uri。当响应返回时,它将首先经过validateheaderhandler,然后传递给timinghandler记录用时,最后返回调用的代码。
总结
虽然我已经展示了创建delegatinghandler并将其添加到httpclient是多么容易,但在大多数情况下,团队并未意识到可以这样做。一些诸如日志记录的常见需求,已经在ihttpclientfactory中考虑到了(将在后面文章中介绍)。对于更复杂的需求,例如失败后重试,更好的选择是使用名叫polly的第三方库。微软团队已决定与polly实现整合。
上一篇: 我的前端布局方法