用于.NET的可移植HTTP客戶端
英文原文：A Portable HTTP Client for .NET
直到最近，關于在 .NET、Silverlight、Windows Phone 和 Windows Store 之間分享代碼的問題之一，依舊是缺少發起 HTTP 請求的能力。每個框架支持一個或多個 HTTP 客戶端，但在 API 層面它們互不兼容。
要解決該問題，開發者可以創建自己的平臺相關適配器，并使用依賴注入把它們添加到有需要的可移植庫中。而基本上，這也正是新的可移植 HttpClient 所做的事情。
當然，每個版本的 HttpClientHandler 都有不同的功能集。所以，為了盡可能地將更多的功能暴露出來，可移植 HTTP 客戶端引入了諸如 SupportsUseProxy 和 SupportsAllowAutoRedirect 這樣的擴展方法。
倘若開發者想要知道為何我們添加擴展方法而不是常規屬性的話：某些 Microsoft.Net.Http 支持的平臺已經提供并正在使用 HttpClientHandler 類。由于不能直接修改屬性的內建版本，我們添加了擴展方法并通過 NuGet 包以獨立程序集的方式發布。
</blockquote>基于以下原因，微軟正在變得越來越青睞類似于可移植 HttpClient 這樣的小型、帶外發布：
首先，它搭建了一座橋梁以跨越我們已經發布的平臺之間的差異。HttpClient 是一個很好的例子，同樣的還有對 async 和 await 關鍵字的支持。帶外發布特性允許我們通過單一可移植類庫針對多平臺發布新功能，而無需等待其中任何一個平臺添加該功能。
其次，我們的目標是增強與客戶之間的反饋回路。過去，我們發布“大型”beta 版本，例如整個 .NET 框架的 beta 版本。這一方法當然有其優勢，但我們也發現了它的問題。其中最大的缺點是“大型”beta 版發布代價高昂，而且它一般與 RTM 非常接近，這也就意味著我們不能再進行重大變更。實際上，我們必須拒絕大量在“大型”beta 版本中獲得的 bug 報告，因為它們僅影響了相對小眾的客戶，或是因為修訂這些 bug 會把 RTM 版本置于風險之中。我們當然不是第一家遇到這個問題的公司；在這個產業里，整個敏捷軟件開發運動都在聚焦于此。雖然我不想開啟關于敏捷方法論的哲學討論，但是很難否認盡早并經常發布對反饋回路的問題是有幫助的。
</blockquote>某些開發者期望的特性未能納入這次候選發布，其中最重要的是對自動解壓縮的支持。為了不推遲本次發布，該特性將在完成后出現在后續版本中。
為了在諸如 Silverlight 等老平臺上支持 async/await，可移植 HttpClient 依賴 BCL 可移植性包。
來自: InfoQ本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！