直到最近，關于在.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客戶端