httpxとは何ですか？

Scrapeless Proxies を使うと、HTTPクライアントは送信リクエストを選択したプロキシ接続経由でルーティングできます。

HTTPX は同期および非同期インターフェースを備えた Python の HTTP クライアントです。リクエストを送信し、接続を管理し、アプリケーションが検査できるレスポンスを公開します。HTTP/1.1 とオプションの HTTP/2 動作をサポートしており、明示的なクライアントライフサイクルを必要とするスクリプト、Webサービス、データコレクタで有用です。

この名前は無関係なソフトウェアを指す場合もあるため、このページは Python ライブラリについて説明します。その最も有用な設計上の特徴は、なじみのあるリクエストの概念を保ったまま実行モデルを選択できることです。引き続きメソッド、URL、ヘッダー、レスポンスボディを扱いますが、非同期クライアントはアプリケーションがレスポンスを待つ方法を変えます。

HTTPX リクエスト中に何が起こるのか？

HTTPX リクエストはアプリケーション設定を宛先へ接続して HTTP メッセージをやり取りするトランスポートに渡します。その結果として、ステータス、ヘッダー、ボディ内容などの情報を含むレスポンスオブジェクトが得られます。 HTTPX クライアントインターフェース は、認証、クッキー、ストリーミング、クライアントレベルの設定もサポートします。

この経路にはいくつか明確に異なる結果があります。接続が確立される前に失敗し、HTTPレスポンスが存在しない場合があります。サーバーが HTTP エラーステータスを返すこともあります。成功ステータスであっても、アプリケーションが利用できないコンテンツを運んでいることがあります。これらを別々のケースとして扱うことで、データパイプラインは実際に何が起きたのかを説明できます。

レスポンスの JSON パーサーを呼び出しても、ボディをデコードするだけです。価格が存在するか、レコードが要求されたアイテムに属しているか、ページネーションが期待した終点に到達したかを検証することはありません。これらの確認はアプリケーション側の責任です。HTTPX は、その判断を行えるトランスポート結果を提供します。

同期クライアントと非同期クライアントはどう違うのか？

同期クライアントは呼び出し側の実行経路で待機するのに対し、非同期クライアントは非同期アプリケーションから await できる操作を公開します。単純な逐次処理には同期 Client を使います。周囲のアプリケーションがすでに非同期処理を調整している場合や、重ね合わせ可能な独立した I/O を持つ場合には AsyncClient を使います。

非同期だからといって自動的に並行実行になるわけではありません。各リクエストが次のリクエスト開始前に await されるコルーチンは依然として逐次的です。スケジューラは、ネットワーク待ち時間が重なり合う前に独立した仕事を受け取る必要があります。また、プログラム側でもアクティブな操作数に対する境界付きポリシーが必要であり、クライアントの種類だけでは完全なワークロードポリシーにはなりません。

例として文書チェッカーを考えると、各文書が前の文書から抽出された値に依存する場合は同期ループで十分かもしれません。チェッカーがすでに独立した URL を多数持っている場合には非同期設計の方が魅力的です。選択は、どちらの構文を好むかではなく、その依存関係に従うべきです。

なぜ再利用可能なクライアントが重要なのか

再利用可能な HTTPX クライアントは、リクエスト間でコネクションプールと共有設定を維持します。再利用可能な接続を再利用することで、同じ宛先への各リクエストごとに新しい接続を確立することを避けられます。これにより接続確立の処理を減らせますが、その利点はワークロードとサーバーが再利用を許可するかどうかに依存します。

クライアントはバッチやサービスコンポーネントなど、一貫したスコープに配置します。毎回の反復内で新しいクライアントを作成すると、プーリングを使う理由の多くが失われます。所有者が終了した後もクライアントを開いたままにすると逆の問題が生じます。ライフサイクルが不明瞭なままリソースが生き続けてしまいます。

クライアントレベルのヘッダーやクッキーもそのスコープ内で持続します。これは一貫した公開データセッションには便利ですが、無関係なコンテキスト間を意図的に分離する必要があります。異なるアカウントや地域を表す観測間で、変更可能なクッキージャーを共有することは避けてください。

接続再利用とリクエスト数は異なる量です。HTTP/2 は 1 本の接続上で複数のリクエストを多重化できますが、HTTP/1.1 は異なる接続動作を行います。最大接続数を、アプリケーション操作数の普遍的な上限と同一視しないでください。アプリケーション側の上限とトランスポートプール設定は、別々の制御として見えるようにしておきましょう。

タイムアウトは異なる待ち段階を識別する

HTTPX は connect、read、write、pool のタイムアウトを区別します。connect タイムアウトは接続確立に関わります。read タイムアウトは受信データの待機に関わります。write タイムアウトはデータ送信に関わり、pool タイムアウトはクライアント内の接続スロットを待つことに関わります。

したがって、pool タイムアウトは宛先が健全であってもローカルの競合を示すことがあります。ストリームが決してクローズされない、あるいはワークロードが自身の接続許容量を超えているクライアントに対しては、リモート側のキャパシティを増やしても解決しません。例外カテゴリと影響を受けた操作を記録し、適切なレイヤーから診断を始められるようにします。

フェーズごとのタイムアウトを、ビジネスタスク全体をカバーする 1 つの締め切りと取り違えてはいけません。HTTPX が呼び出される前にアプリケーションのキューでジョブが待機することもあれば、リクエスト終了後にデータをパースしたり保存したりすることもあります。タスクに総合的な締め切りがある場合は、それを別途追跡してください。

タイムアウト値はアプリケーションの契約と観測されたワークロードから選びます。小さなメタデータレスポンスと大きな許可されたダウンロードでは要求が異なります。すべての制限を取り払うとリソースが無期限に占有されかねず、すべての制限を極端に短くすると、本来はタスクを満たせたはずの仕事を拒否してしまう可能性があります。

レスポンスを正しく検証する方法

レスポンス検証は、トランスポートの成功、HTTP の意味、アプリケーションコンテンツをその順序で確認します。 HTTP セマンティクス標準 メソッドとステータスの意味を定義しますが、成功ステータスであってもあなたの抽出ロジックが正しいことを証明するわけではありません。有効なレスポンスであっても、あなたの作業に対して誤ったリソースを記述している可能性があります。

要求された最初と最終的な URL から開始します。リダイレクト追跡が有効な場合は、クライアントが到達した場所を確認します。その後、ボディをデコードする前にメディアタイプを確認します。デコード後、想定されるフィールドとその型を検証します。拒否された各レスポンスについては、その理由を必ず保持し、空のデータセットが黙ってポジティブなビジネス上の発見にならないようにします。

たとえば、製品に関する観測データには、製品識別子と通貨、および価格が必要になる場合があります。価格が存在する一方で通貨が欠けている場合、アプリケーションは追加の文脈なしに、その値を市場横断的な比較に統合すべきではありません。これはクライアントライブラリとは独立した、データモデル上のルールです。

欠損している値と、空のコレクションや明示的なゼロ値は区別してください。欠損している在庫フィールドがあっても、在庫がゼロであることの証明にはなりません。エントリが 1 つもない JSON 配列は、その周囲のレスポンスがクエリが受理され正常に完了したことを確認している場合にのみ、正当な結果となり得ます。

ストリーミングには明示的なライフタイムが必要です

ストリーミングを利用すると、アプリケーションはレスポンス全体を処理前に読み込むのではなく、少しずつ逐次的に消費できるようになります。これは大きなファイルやフィードに対して有用ですが、同時にリソースに関する義務も生じます。つまり、クライアントのインターフェースに従って、ストリームを消費するか、または閉じなければなりません。

コンテキスト管理されたストリームは、その義務に明確な境界を与えます。検証が早い段階で失敗した場合でも、コンテキストを抜けることでストリームは確実にクローズされるべきです。部分的にしか消費されていないレスポンスを開いたままにしておくと、コネクションプールを使い果たし、無関係なリクエストが、原因不明に利用不能に見えるリソースを待たされることになり得ます。

インクリメンタル入力はパーサ設計も変更します。チャンク境界はトランスポート境界であり、必ずしも完全な JSON オブジェクト、テキスト文字、またはアプリケーションレコードではありません。形式に適したパーサを使用し、次のチャンクが到着するまで不完全なデータを保持してください。1 つのチャンクが 1 つの意味のあるレコードに相当すると仮定してはいけません。

プロキシルーティングと証明書検証

プロキシは HTTPX トラフィックを仲介サーバー経由でルーティングし、一方で TLS 検証はクライアントが想定するセキュアなエンドポイントを認証します。これらの制御は、異なる問いに答えるものです。プロキシ接続が動作していることは証明書検証を無効化する根拠にはならず、検証済みの証明書からは、どの地理的出口が選択されたかは分かりません。

The TLS セキュリティプロトコル HTTPS で使用される暗号化された転送を提供します。HTTP プロキシを経由した従来の HTTPS トンネルでは、クライアントはそのトンネルを通じて宛先との TLS を確立できます。明示的に構成された検査プロキシは異なる信頼モデルを持ち、そのようなものとして評価されるべきです。

現在を使用 スクレイプレスプロキシのセットアップ 正しい接続情報を取得します。プロキシ認証情報はソース管理の外に保管し、認証情報を含む場合は、ログから完全なプロキシ URL を編集（マスキング）してください。関連する HTTPX と Scrapeless プロキシのウォークスルー 有用な背景情報ではあるが、歴史的な例は現在の製品設定と整合させる必要がある。

スクレイプレスプロキシソリューション リクエストやパース処理の制御を維持するアプリケーション向けのネットワークコンポーネントを提供します。選択した製品の動作を比較し、 現在の料金 大規模な実行に進む前に、バッチ要件を確認してください。

HTTPX が行わないこと

HTTPX はページの JavaScript を実行せず、ブラウザーインターフェイスもレンダリングしません。レスポンスにアプリケーションシェルが含まれている場合、HTTPX はそのシェルを返します。必要なコンテンツがブラウザーの実行やインタラクションの後にのみ存在する場合、アプリケーションは別の収集方法を用意する必要があります。

HTTPX もまた、ブラウザが行うようにすべてのレスポンスを自動的にキャッシュするわけではありません。HTTP キャッシュには、独自のストレージ、鮮度、および検証ルールがあり、次の仕様で定義されています HTTP キャッシュ仕様. あらゆるアプリケーションキャッシュを、明確なキーと鮮度ポリシーを備えた独立したコンポーネントとして扱うこと。

クライアントを変更しても、リソースへのアクセス権限が確立されるわけではありません。ワークフローに適した、文書化されたインターフェースおよび許可されたページを使用してください。別のクライアントが異なる応答を返したとしても、認証要件は依然として境界として残ります。

結論

HTTPX は、Python アプリケーションに同期および非同期の HTTP 操作の間で明確な選択肢を提供します。所有するスコープ内でクライアントを再利用し、タイムアウトをステージ別に分類し、レスポンスストリームをクローズします。HTTP ステータスを最終結果として扱うのではなく、返されたコンテンツをタスクに照らして検証したうえでのみデータを受け入れます。