PyPIパッケージ: olostep | 要件: Python 3.11+
インストール
認証
Olostep DashboardからAPIキーを取得してください。クイックスタート
SDKは、使用ケースに応じて2つのクライアントオプションを提供します:同期クライアント (`Olostep`)
最適な用途: スクリプトや、ブロッキング操作を好むシンプルな使用ケース。
同期クライアントは、非同期/待機に不慣れな場合に始めやすいシンプルなブロッキングインターフェースを提供します。
同期クライアントは、非同期/待機に不慣れな場合に始めやすいシンプルなブロッキングインターフェースを提供します。
非同期クライアント (`AsyncOlostep`)
最適な用途: 本番アプリケーションや、多くの同時リクエストを処理する場合。
非同期クライアントはノンブロッキング操作を提供し、高スループットが必要な本番アプリケーションに推奨されます。
非同期クライアントはノンブロッキング操作を提供し、高スループットが必要な本番アプリケーションに推奨されます。
同期クライアント (Olostep)
同期クライアント (Olostep) は、スクリプトやシンプルな使用ケースに最適なブロッキングインターフェースを提供します。
基本的なウェブスクレイピング
バッチ処理
スマートウェブクロール
サイトマッピング
AI駆動の回答
非同期クライアント (AsyncOlostep)
非同期クライアント (AsyncOlostep) は、高性能アプリケーション、バックエンドサービス、および多くの同時リクエストを処理する必要がある場合に推奨されるクライアントです。
基本的なウェブスクレイピング
バッチ処理
スマートウェブクロール
サイトマッピング
AI駆動の回答
SDKリファレンス
メソッド構造
両方のSDKクライアントは、論理的な名前空間に整理されたクリーンでPython的なインターフェースを提供します:
各操作は、後続の操作のためのエルゴノミックなメソッドを持つステートフルオブジェクトを返します。
エラーハンドリング
すべてのSDKエラーを基本例外クラスでキャッチします:自動リトライ
SDKは一時的なエラー(ネットワークの問題、一時的なサーバーの問題)に対して自動的にリトライを行います。RetryStrategy設定に基づいてリトライ動作をカスタマイズできます。クライアントを作成する際にRetryStrategyインスタンスを渡すことでリトライ動作をカスタマイズできます:
高度な機能
スマート入力強制
SDKは、最大限の利便性を提供するためにさまざまな入力フォーマットをインテリジェントに処理します:高度なスクレイピングオプション
キャッシング
デフォルトでは、すべてのスクレイプリクエストは新しいページを取得します(max_age=0)。同じパラメータで最近の結果を再利用し、応答時間を改善するためにmax_ageを渡します。値は秒で、最大は7日間(604800)です。詳細については、キャッシングを参照してください。
カスタム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がリクエストを処理する前に発生するネットワークレベルの失敗を表します。これらはトランスポート層の問題(DNSまたはHTTPの失敗、タイムアウト、接続拒否など)であり、APIレベルのエラーではありません。HTTPステータスコード(4xx、5xx)はAPI応答と見なされ、サーバーエラーとして分類されますが、問題を示しています。
推奨エラーハンドリング
ほとんどの使用ケースでは、基本エラーをキャッチしてエラー名を出力します:OlostepServerError_AuthFailed)は、問題を理解するのに十分な説明的です。
詳細なエラーハンドリング
より具体的なエラーハンドリングが必要な場合は、直接特定のエラータイプをキャッチします。OlostepServerError_BaseErrorまたはOlostepClientError_BaseErrorを使用しないでください - これらの基本クラスは、エラーを誰が発生させたかを示すだけで、誰が修正する責任があるかを示しません。これはエラーハンドリングロジックには役立たない実装の詳細です。
代わりに、実際の問題を示す特定のエラータイプをキャッチします:
設定
環境変数
ヘルプを得る
リソース
PyPIパッケージ
PyPIで表示
APIキーを取得
無料でサインアップ