.NET、Silverlight、Windows Phone、Windows Storeでコードを共有する上で、最近までの問題のひとつはHTTPリクエストができないことであった。各フレームワークはひとつ以上のHTTPクライアントをサポートしているが、APIレベルでそれぞれ互換性がなかった。
これを回避するために開発者は自信のプラットフォーム固有のアダプタを開発して、それに必要なポータブルライブラリを追加するために依存性注入を使用することができる。そして本質的に、新しいポータブルHttpClientはあなたになにをもたらすのか。
もちろん各バージョンのHttpClientHandlerは異なる機能の組み合わせを持っている。可能な限り多くの機能を公開するためにSupportsUseProxyとSupportsAllowAutoRedirectと言った拡張メソッドを提供している。
Immo Landwerth氏は次のように説明する
私たちが通常のプロパティではなく、なぜ拡張メソッドを追加したのか不思議に思うでしょう: いくつかのプラットフォームにおいてMicrosoft.Net.Httpはすでに、そのプラットフォームでしようできるHttpClientHandlerクラスを提供しています。私たちは、直接組み込みバージョンのプロパティを変更することができないため、NuGetパッケージで配布される別アセンブリに拡張メソッドを追加しました。
ポータブルHttpClientのような、小さな、アウトオブバンドなリリースは、次の2つの理由からMicrosoftにおいてよりポピュラーになるだろう
はじめに、私たちがすでに出荷したプラットフォームとの間の機能の差を埋めることができる。HttpClientはよい例で、asyncとawaitキーワードのサポートも含まれています。アウトオブバンドの機能リリースはまた、あるプラットフォームに機能が追加されるのを待つことなく、ひとつのポータブルクラスライブラリで複数のプラットフォームに新しい機能を提供することを可能にします。
ふたつめに、私たちのゴールはあなたや私たちのお客様のフィールドバックループを強化することです。以前は私たちは.NET Framework全体のベータのような“大きな”リリースをしてきました。このアプローチは確かにいくつかの利点がありますが、問題点も見つかりました。最大の欠点は、“大きな”ベータをリリースすることは非常に負荷が大きく、一般的にRTMに必要に近く、逆に言えば、私たちはもう大きなインパクトのある変更を加えることができないことを意味しています。実際に私たちは、“大きな”ベータで多くのバグレポートを受け取りますが、それらは比較的少数の顧客に影響を与えるか、RTMリリースでバグを修正して置き換えるリスクになるかのどちらかです。私たちは確かにこの問題を行っている最初の会社ではないが、私たちの業界全体でここにフォーカスを当ててアジャイルソフトウェア開発を行う動きがあります。私はアジャイル方法論の哲学的な議論をしたくはないが、早くリリースしてフィードバックループの問題を頻繁に手助けすることを否定することは非常に難しい。
開発者が望んでいるいくつかの機能は、このリリース候補では提供されていない。もっとも重要なものは自動解凍のサポートである。リリースを遅らせるのではなく、単純にその機能が準備できたらフォローアップリリースを提供しようとしているのである。
Silverlightのように古いプラットフォームでasync/awaitをサポートするためにポータブルHttpClientはBCL Portability Packに依存している。