直到最近，关于在.NET、Silverlight、Windows Phone 和 Windows Store 之间分享代码的问题之一，依旧是缺少发起 HTTP 请求的能力。每个框架支持一个或多个 HTTP 客户端，但在 API 层面它们互不兼容。
要解决该问题，开发者可以创建自己的平台相关适配器，并使用依赖注入把它们添加到有需要的可移植库中。而基本上，这也正是新的可移植 HttpClient 所做的事情。
当然，每个版本的 HttpClientHandler 都有不同的功能集。所以，为了尽可能地将更多的功能暴露出来，可移植 HTTP 客户端引入了诸如 SupportsUseProxy 和 SupportsAllowAutoRedirect 这样的扩展方法。
倘若开发者想要知道为何我们添加扩展方法而不是常规属性的话：某些 Microsoft.Net.Http 支持的平台已经提供并正在使用 HttpClientHandler 类。由于不能直接修改属性的内建版本，我们添加了扩展方法并通过 NuGet 包以独立程序集的方式发布。
基于以下原因，微软正在变得越来越青睐类似于可移植 HttpClient 这样的小型、带外发布：
首先，它搭建了一座桥梁以跨越我们已经发布的平台之间的差异。HttpClient 是一个很好的例子，同样的还有对 async 和 await 关键字的支持。带外发布特性允许我们通过单一可移植类库针对多平台发布新功能，而无需等待其中任何一个平台添加该功能。
其次，我们的目标是增强与客户之间的反馈回路。过去，我们发布“大型”beta 版本，例如整个.NET 框架的 beta 版本。这一方法当然有其优势，但我们也发现了它的问题。其中最大的缺点是“大型”beta 版发布代价高昂，而且它一般与 RTM 非常接近，这也就意味着我们不能再进行重大变更。实际上，我们必须拒绝大量在“大型”beta 版本中获得的 bug 报告，因为它们仅影响了相对小众的客户，或是因为修订这些 bug 会把 RTM 版本置于风险之中。我们当然不是第一家遇到这个问题的公司；在这个产业里，整个敏捷软件开发运动都在聚焦于此。虽然我不想开启关于敏捷方法论的哲学讨论，但是很难否认尽早并经常发布对反馈回路的问题是有帮助的。
某些开发者期望的特性未能纳入这次候选发布，其中最重要的是对自动解压缩的支持。为了不推迟本次发布，该特性将在完成后出现在后续版本中。
为了在诸如 Silverlight 等老平台上支持 async/await，可移植HttpClient 依赖 BCL 可移植性包。
查看英文原文： A Portable HTTP Client for .NET
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论