PyPIパッケージ: olostep | 要件: Python 3.11+
インストール
認証
Olostep DashboardからAPIキーを取得してください。クイックスタート
SDKは、使用ケースに応じて2つのクライアントオプションを提供します:同期クライアント (Olostep)
最適: スクリプトやシンプルなユースケースで、ブロッキング操作を好む場合。
同期クライアントは、非同期/待機に不慣れな場合でも簡単に始められるシンプルなブロッキングインターフェースを提供します。
同期クライアントは、非同期/待機に不慣れな場合でも簡単に始められるシンプルなブロッキングインターフェースを提供します。
非同期クライアント (AsyncOlostep)
最適: 本番アプリケーションや多数の同時リクエストを処理する場合。
非同期クライアントは非ブロッキング操作を提供し、高スループットが必要な本番アプリケーションに推奨されます。
非同期クライアントは非ブロッキング操作を提供し、高スループットが必要な本番アプリケーションに推奨されます。
同期クライアント (Olostep)
同期クライアント (Olostep) は、スクリプトやシンプルなユースケースに最適なブロッキングインターフェースを提供します。
基本的なWebスクレイピング
バッチ処理
スマートWebクローリング
サイトマッピング
AI駆動の回答
非同期クライアント (AsyncOlostep)
非同期クライアント (AsyncOlostep) は、高性能アプリケーション、バックエンドサービス、および多数の同時リクエストを処理する必要がある場合に推奨されるクライアントです。
基本的なWebスクレイピング
バッチ処理
スマートWebクローリング
サイトマッピング
AI駆動の回答
SDKリファレンス
メソッド構造
両方のSDKクライアントは、論理的な名前空間に整理された同じクリーンでPython的なインターフェースを提供します:
各操作は、フォローアップ操作のための使いやすいメソッドを持つステートフルオブジェクトを返します。
エラーハンドリング
すべてのSDKエラーを基底例外クラスでキャッチします:自動リトライ
SDKは、RetryStrategy構成に基づいて、一時的なエラー(ネットワークの問題、一時的なサーバーの問題)に対して自動的にリトライします。クライアントを作成する際にRetryStrategyインスタンスを渡すことで、リトライの動作をカスタマイズできます:
高度な機能
スマート入力強制
SDKは、最大限の利便性のためにさまざまな入力フォーマットをインテリジェントに処理します:高度なスクレイピングオプション
キャッシング
デフォルトでは、すべてのスクレイプリクエストは新しいページをフェッチします(max_age=0)。同じパラメータで最近の結果を再利用して応答時間を改善するには、max_ageを渡します。値は秒で、最大は7日間(604800)です。詳細については、キャッシングを参照してください。
ストレージ
デフォルトでは、スクレイプ結果は約7日間保持されます。storageをexpires_inに10d、30d、60d、90d、180d、365d、またはneverを設定して、より長く保持します。詳細については、ストレージを参照してください。
カスタムIDを使用したバッチ処理
インテリジェントクローリング
フィルタ付きサイトマッピング
回答の取得
コンテンツの取得
ロギング
問題をデバッグするためにロギングを有効にします:INFO (推奨), DEBUG (詳細), WARNING, ERROR
リトライ戦略の構成
RetryStrategyクラスは、エクスポネンシャルバックオフとジッターを使用した自動リトライを通じて、Olostep SDKが一時的なAPIエラーをどのように処理するかを制御します。これにより、一時的なネットワークの問題、レート制限、サーバーの過負荷が原因で発生する断続的な失敗がある場合でも、信頼性の高い操作が可能になります。
デフォルトの動作
デフォルトでは、SDKは以下のリトライ構成を使用します:- 最大リトライ回数: 5回の試行
- 初期遅延: 2秒
- バックオフ: エクスポネンシャル (2^試行)
- ジッター: 遅延の10-90% (ランダム化)
- 試行1: 即時
- 試行2: 約2-3.6秒の遅延
- 試行3: 約4-7.2秒の遅延
- 試行4: 約8-14.4秒の遅延
- 試行5: 約16-28.8秒の遅延
カスタム構成
リトライが発生する場合
SDKは以下の状況で自動的にリトライします:- 一時的なサーバーの問題 (
OlostepServerError_TemporaryIssue) - タイムアウト応答 (
OlostepServerError_NoResultInResponse)
トランスポートと呼び出し元のリトライ
SDKには2つのリトライレイヤーがあります:- トランスポートレイヤー: ネットワークレベルの接続失敗を処理(DNS、タイムアウトなど)
- 呼び出し元レイヤー: APIレベルの一時的なエラーを処理(
RetryStrategyによって制御)
最大期間の計算
構成例
さまざまなユースケースに対するリトライ戦略の構成例を以下に示します。保守的な戦略
攻撃的な戦略
リトライなし(即時失敗)
高スループット戦略
ジッターの理解
ジッターは、クライアントが同時にリトライする際の「サンダリングハード」問題を防ぐためにランダム化を追加します。ジッターは次のように計算されます:initial_delay=2.0、jitter_min=0.1、jitter_max=0.9の場合:
- 試行0: base=2.0s, jitter=0.2-1.8s, final=2.2-3.8s
- 試行1: base=4.0s, jitter=0.4-3.6s, final=4.4-7.6s
- 試行2: base=8.0s, jitter=0.8-7.2s, final=8.8-15.2s
ベストプラクティス
本番アプリケーション向け
開発/テスト向け
バッチ操作向け
モニタリングとデバッグ
SDKはDEBUGレベルでリトライ情報をログに記録します:エラーハンドリング
すべてのリトライが尽きた場合、元のエラーが発生します:パフォーマンスの考慮事項
- メモリ: 各リトライ試行は、リクエスト/レスポンスオブジェクトの追加メモリを使用します
- 時間: リトライを有効にすると、全体の操作時間が大幅に長くなる可能性があります
- API制限: リトライはAPI使用制限にカウントされます
- ネットワーク: リトライ試行によるネットワークトラフィックの増加
詳細なエラーハンドリング
例外階層
Olostep SDKは、さまざまな失敗シナリオに対する包括的な例外階層を提供します。すべての例外はOlostep_BaseErrorから継承されます。
Olostep_BaseErrorから直接継承される3つの主要なエラータイプがあります:
Olostep_APIConnectionError- ネットワークレベルの接続失敗OlostepServerError_BaseError- APIサーバーによって発生した(ある種の)エラーOlostepClientError_BaseError- クライアントSDKによって発生したエラー
なぜ接続エラーが別なのか
Olostep_APIConnectionErrorは、APIがリクエストを処理する前に発生するネットワークレベルの失敗を表すため、サーバーエラーとは別です。これらは、APIレベルのエラーではなく、トランスポートレイヤーの問題(DNSまたはHTTPの失敗、タイムアウト、接続拒否など)です。HTTPステータスコード(4xx、5xx)はAPI応答と見なされ、サーバーエラーとして分類されますが、問題を示しています。
推奨されるエラーハンドリング
ほとんどのユースケースでは、基底エラーをキャッチしてエラー名を出力します:OlostepServerError_AuthFailed)は、問題を理解するのに十分な説明です。
詳細なエラーハンドリング
より具体的なエラーハンドリングが必要な場合は、特定のエラータイプを直接キャッチします。OlostepServerError_BaseErrorまたはOlostepClientError_BaseErrorを使用しないでください - これらの基底クラスは、エラーを誰が発生させたかを示すだけで、誰が修正する責任があるかを示しません。これはエラーハンドリングロジックには役立たない実装の詳細です。
代わりに、実際の問題を示す特定のエラータイプをキャッチします:
構成
環境変数
ヘルプを得る
リソース
PyPIパッケージ
PyPIで表示
APIキーを取得
無料でサインアップ