いくつかの例外を除き、WinINet は WinHTTP のスーパーセットです。 2 つを選択するときは、偽装とセッション分離 を必要とするサービスまたはサービスのようなプロセス内で実行する予定がない限り、WinINetを使用する必要があります。
機能の比較
関連トピック
クイック デシジョン ガイド
次のフローチャートを使用して、適切な HTTP クライアント スタックを選択します。
-
コードは、Windows サービス、システム プロセス、または偽装の下で実行されていますか?
- はい → WinHTTP を使用します。
-
コードは、ユーザーのインターネット オプション (IE) プロキシ設定、Cookie、または資格情報プロンプトを必要とするデスクトップ アプリですか?
- はい→ WinINet を使用します。
-
最新の C++ デスクトップまたは UWP/WinUI アプリを作成していますか?
- はい → Windows.Web.Http を使用します（Windows.Web.Http 名前空間経由の C++/WinRT）。
-
.NET アプリケーションを作成していますか?
- はい → System.Net.Http.HttpClient を使用します。
-
クロスプラットフォームの互換性が必要ですか?
- はい → libcurl または同様のポータブル ライブラリを使用します。
Note
WinINet と WinHTTP の両方を使用しない場合 — 新しいアプリケーションを構築していて、従来の Win32 統合を必要としない場合は、上記の最新の代替手段を使用します。 これらは、よりシンプルな API とより優れた非同期サポートを提供します。 一部の代替手段には、追加の利点もあります。たとえば、libcurl と .NET HttpClient はクロスプラットフォームであり、TLS 1.3 の可用性は基盤となる TLS スタックと OS の構成によって異なります。 Win32 サービスのサポート、ブラウザー資格情報の共有、または詳細なプロキシ統合が特に必要なシナリオでは、WinHTTP/WinINet を予約します。
Important
セキュリティアラーム — 選択した HTTP スタックに関係なく、運用環境で TLS 証明書の検証を無効にしないでください。 WinHTTP と WinINet の両方で、フラグを使用して証明書エラーを無視できますが、これを行うと、アプリケーションが中間者攻撃にさらされます。