Fork me on GitHub

用于.NET的可移植HTTP客户端

直到最近,关于在.NET、Silverlight、Windows Phone和Windows Store之间分享代码的问题之一,依旧是缺少发起HTTP请求的能力。每个框架支持一个或多个HTTP客户端,但在API层面它们互不兼容。

要解决该问题,开发者可以创建自己的平台相关适配器,并使用依赖注入把它们添加到有需要的可移植库中。而基本上,这也正是新的可移植HttpClient所做的事情。

当然,每个版本的HttpClientHandler都有不同的功能集。所以,为了尽可能地将更多的功能暴露出来,可移植HTTP客户端引入了诸如SupportsUseProxy和SupportsAllowAutoRedirect这样的扩展方法。

Immo Landwerth解释道:

倘若开发者想要知道为何我们添加扩展方法而不是常规属性的话:某些Microsoft.Net.Http支持的平台已经提供并正在使用HttpClientHandler类。由于不能直接修改属性的内建版本,我们添加了扩展方法并通过NuGet包以独立程序集的方式发布。

基于以下原因,微软正在变得越来越青睐类似于可移植HttpClient这样的小型、带外发布:

首先,它搭建了一座桥梁以跨越我们已经发布的平台之间的差异。HttpClient是一个很好的例子,同样的还有对async和await关键字的支持。带外发布特性允许我们通过单一可移植类库针对多平台发布新功能,而无需等待其中任何一个平台添加该功能。

其次,我们的目标是增强与客户之间的反馈回路。过去,我们发布“大型”beta版本,例如整个.NET框架的beta版本。这一方法当然有其优势,但我们也发现了它的问题。其中最大的缺点是“大型”beta版发布代价高昂,而且它一般与RTM非常接近,这也就意味着我们不能再进行重大变更。实际上,我们必须拒绝大量在“大型”beta版本中获得的bug报告,因为它们仅影响了相对小众的客户,或是因为修订这些bug会把RTM版本置于风险之中。我们当然不是第一家遇到这个问题的公司;在这个产业里,整个敏捷软件开发运动都在聚焦于此。虽然我不想开启关于敏捷方法论的哲学讨论,但是很难否认尽早并经常发布对反馈回路的问题是有帮助的。

某些开发者期望的特性未能纳入这次候选发布,其中最重要的是对自动解压缩的支持。为了不推迟本次发布,该特性将在完成后出现在后续版本中。

为了在诸如Silverlight等老平台上支持async/await,可移植HttpClient依赖BCL可移植性包

相关文章:

Portable HttpClient for .NET Framework and Windows Phone

Get /httpclient/rtm – 200 OK

第13周的NuGet包—Portable HttpClient使得portable libraries更加好用

CFNetwork-powered HttpClient

Google API的.NET可移植类库1.4.0测试版发布

查看英文原文:A Portable HTTP Client for .NET

查看中文原文:用于.NET的可移植HTTP客户端

posted @ 2013-06-03 07:13 张善友 阅读(...) 评论(...) 编辑 收藏