OSS.Http プロジェクトの .Net Standard 標準ライブラリのサポートは移行されており、OSS オープン ソース シリーズの 2 つの最下位クラス ライブラリはすでにクロス ランタイムをサポートする機能を備えています。この記事では主に、1. HttpClient の概要、2. 再構築のアイデア、3. 遭遇しやすい問題について説明します。非常に優れた参考値です。以下のエディターで見てみましょう
OSS.Http プロジェクトの .Net Standard 標準ライブラリのサポートは移行されており、OSS オープン ソース シリーズの 2 つの最下位クラス ライブラリはすでに移行されていますクロスランタイムサポート機能を備えています。 OSS.Http クラス ライブラリは、RestSharp のアイデアに基づいて私が数年前に完成させた軽量の Http リクエスト フレームワークであるためです。最下位層は長い間 HttpWebRequest を使用してきたため、今回は基本的に完全にリファクタリングされました。この記事では主に 1. HttpClient の概要、2. リファクタリングのアイデア、3. 遭遇しやすい問題について説明します。
1. httpclient の基本的な紹介
HttpClient は .net Framework バージョン 4.5 あたりで参照される新しい機能である必要があります。これに比べて、前者の方がより単純で明確です。 .net 標準 API を完全にサポートしていることも、これを選択した重要な理由です。
HttpClient は構造的に大幅に調整されており、完全に非同期実装であると言えます。ここで、対応するメイン クラスをまず紹介します:
1.リクエストの情報、リクエストアドレス、リクエストアクションなど。この値はリクエストを開始するHttpClientのメソッドにパラメータとして渡され、HttpResponseMessage
2に対するリクエストの内容に相当します。
本文には主に、HtttpRequestMessage の属性である、リクエストの特定のコンテンツが含まれます。どちらも Headers 属性を含みますが、これは混乱が生じる領域です。エラーが発生しやすいため、簡単に分類しました: HttpRequestMessage のヘッダー (HttpRequestHeaders) は、主に Accept、UserAgent、AcceptEncoding などのリクエストの属性、および http リンクのその他の基本属性です。
HttpContent のヘッダー (HttpContentHeaders) は、主に現在のリクエスト コンテンツの属性であり、主に次のものが含まれます:Allow、Content-Encoding、Content-Length、Content-Type、Expires、Last-Modified など。詳細については、公式を参照してください。クラスライブラリ。
HttpContent システムは、主に次のようないくつかのデフォルト実装を提供します:
3. HttpMessageHandler
このクラスの主な機能は、リダイレクトをサポートするかどうかなど、コンテンツ処理アクションの定義を要求することです。 Cookie、プロキシ Proxy などを使用してシステム設定を優先できるかどうか。この値は、HttpClient コンストラクターを通じて渡すことができます。システムによって提供されるデフォルトのサブクラスは HttpClientHandler です。
4. HttpClient
特定のリクエスト実装呼び出し実装、POST、GET、Delete およびその他の Http リクエスト メソッドの完全な実装、すべてのメソッドは最終的に SendAsync メソッドを呼び出します。 上記の 4 つの主要なクラスは、HttpClient リクエストの主要な実装を構成します。単純に使用するだけであれば、次のように HttpClient についてのみ考慮する必要があります:
実際、HttpRequestMessage と HttpClientHandler はデフォルトで内部に実装されています。それ。簡単に紹介しましたが、基本的に HttpClient の実装は非常に明確な分業化されていることがわかります。以前のようにすべての設定が WebRequest に集中しているということはありません。明確な役割分担の最も直接的な利点は、HttpClient が複数のリクエストを共有できることです。ブログ投稿を参照してください:
デフォルトの HttpClient は、単一の HttpClient を使用して多くのリクエストを送信できることです。 HTTP リクエストを同時に必要に応じて実行できるため、多くのシナリオでは、HttpClient を 1 つ作成するだけで、それをすべてのリクエストに使用できます。
つまり、システム内でさまざまなリクエストを開始したい場合は、基本的に HttpClient を共有する代わりに、HttpClient を共有できます。すべてのリクエストに HttpWebReqest を要求することで、リソースの消費を削減します。
2. OSS.Http を再構築するトピックに戻り、現在のコード モジュールを再構築します。前述したように、.Net Standard は httpWebRequest をまったくサポートしていないため、直接それを再実装することになりました。 httpWebRequest は単純であるため、基本的に上位層は基本的に RestSharp のコアを実装するコードを参照する必要はありません。 http 古い支店。 再構築前は HttpClient についてあまり知らなかったため、既存のフレームワークのプロセスを継続して実装を変換したいと考えていました。しかし、クライアントのドキュメントを見直して調査した結果、多くのカプセル化が完全に不要であることがわかり、プロセスも変更されていたため、元のフレームワークで多くのものを削除し、最終的な実装を再配置しました。
もちろん、HttpClient の現在の実装自体は十分にシンプルで明確ですが、多くの場合、POST、GET、およびその他のメソッドを直接呼び出すと、一部のコードの再利用が減ります。たとえば、OSS.Social プロジェクトでは、次のことだけが必要です。一番下に RestCommon メソッドを実装します。つまり、グローバルなリクエスト制御を実現でき、呼び出し元は URL、HttpMothed、およびパラメーターを提供するだけで済みます。
ここではプレゼンテーションとして簡単なフローチャートを描きました:
基本的にプロセスに大きな違いはありません。コードは Github にあります。 ファイルの構造は次のとおりです。
Mos ファイルの下: Enum.cs 列挙クラス、FileParameter .cs ファイル パラメータ クラス、FormParameter フォーム フォーム パラメータ クラス、OsHttpRequest リクエスト パラメータ クラス、
OsRest.cs は、同時に HttpClient を確実に実行するための主要な実装です。 OsRest 自体はユニバーサル機能を備えており、HttpClient から継承し、RestSend メソッドも提供します。このメソッドはプロセスの実装を完了し、最後に SendAsync メソッドを呼び出して要求を実行します。
RestUtil.cs 補助クラス。グローバル OsRest (HttpClient) の共有を完了し、デフォルトの HttpClientHandler 実装を定義します。このクラスを直接呼び出すだけです。
プロセス内の実行ユーザー定義設定は、OSHttpRequest の RequestSet デリゲート属性で設定できます。たとえば、アクセス タイプを json に設定できます。
3. 発生しやすい問題
全体の再構築ですが、最後に残っているコードはそれほど多くありませんが、まだ共有できる問題がいくつかあるはずです
1. ヘッダーの割り当ての問題については、最初の部分を参照してください。ヘッダー、そうでない場合は、エラー
2. 上記のフローチャートでは、Get リクエストであるため、「Get であるかどうか」の判断があることがわかります。 , HttpWebReqest と同様に、コンテンツに値を割り当てることはできません。取得リクエストが GetRequestStream メソッドを呼び出すと、「この述語タイプではコンテンツ本文を送信できません」という例外エラーが発生します。もちろん、OSS.Http をリクエストとして使用している場合は、そのような問題は発生しません。
3. ファイルアップロードと同時にアップロードされるフォームパラメータは、別途フォームパラメータを送信する場合とは異なりますので、OsRestクラスの参照方法がわからない場合は注意してください。加工されています。
上記は、標準ライブラリをサポートするための OSS.Http の基礎となる HttpClient の再構築とカプセル化の詳細な紹介です。その他の関連コンテンツについては、PHP 中国語 Web サイト (www.php.cn) に注目してください。