PyPIパッケージ: olostep | 要件: Python 3.11+
インストール
認証
Olostep DashboardからAPIキーを取得してください。クイックスタート
SDKは、使用ケースに応じて2つのクライアントオプションを提供します:同期クライアント (`Olostep`)
最適な用途: スクリプトや単純な使用ケースで、ブロッキング操作を好む場合。
同期クライアントは、非同期/awaitに不慣れな場合でも、簡単に始められるシンプルなブロッキングインターフェースを提供します。
同期クライアントは、非同期/awaitに不慣れな場合でも、簡単に始められるシンプルなブロッキングインターフェースを提供します。
非同期クライアント (`AsyncOlostep`)
最適な用途: 本番アプリケーションや、多くの同時リクエストを処理する場合。
非同期クライアントは非ブロッキング操作を提供し、高スループットが必要な本番アプリケーションに推奨されます。
非同期クライアントは非ブロッキング操作を提供し、高スループットが必要な本番アプリケーションに推奨されます。
同期クライアント (Olostep)
同期クライアント (Olostep) は、スクリプトや単純な使用ケースに最適なブロッキングインターフェースを提供します。
基本的なウェブスクレイピング
バッチ処理
スマートウェブクロール
サイトマッピング
AI駆動の回答
非同期クライアント (AsyncOlostep)
非同期クライアント (AsyncOlostep) は、高性能アプリケーション、バックエンドサービス、および多くの同時リクエストを処理する必要がある場合に推奨されます。
基本的なウェブスクレイピング
バッチ処理
スマートウェブクロール
サイトマッピング
AI駆動の回答
SDKリファレンス
メソッド構造
両方のSDKクライアントは、論理的な名前空間に整理されたクリーンでPython的なインターフェースを提供します:| 名前空間 | 目的 | 主要メソッド |
|---|---|---|
scrapes | 単一URL抽出 | create(), get() |
batches | 複数URL処理 | create(), info(), items() |
crawls | ウェブサイト巡回 | create(), info(), pages() |
maps | リンク抽出 | create(), urls() |
answers | AI駆動の抽出 | create(), get() |
retrieve | コンテンツ取得 | get() |
エラーハンドリング
すべてのSDKエラーをベース例外クラスでキャッチします:自動リトライ
SDKは、RetryStrategy構成に基づいて、一時的なエラー(ネットワークの問題、一時的なサーバーの問題)に対して自動的にリトライします。クライアントを作成する際にRetryStrategyインスタンスを渡すことで、リトライ動作をカスタマイズできます:
高度な機能
スマート入力強制
SDKは、最大の利便性のためにさまざまな入力フォーマットをインテリジェントに処理します:高度なスクレイピングオプション
カスタム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.0秒, jitter=0.2-1.8秒, final=2.2-3.8秒
- 試行1: base=4.0秒, jitter=0.4-3.6秒, final=4.4-7.6秒
- 試行2: base=8.0秒, jitter=0.8-7.2秒, final=8.8-15.2秒
ベストプラクティス
本番アプリケーション向け
開発/テスト向け
バッチ操作向け
モニタリングとデバッグ
SDKは、DEBUGレベルでリトライ情報をログに記録します:エラーハンドリング
すべてのリトライが尽きた場合、元のエラーが発生します:パフォーマンスの考慮事項
- メモリ: 各リトライ試行は、リクエスト/レスポンスオブジェクトのために追加のメモリを使用します
- 時間: リトライが有効な場合、総操作時間が大幅に長くなる可能性があります
- API制限: リトライはAPI使用制限にカウントされます
- ネットワーク: リトライ試行によるネットワークトラフィックの増加
詳細なエラーハンドリング
例外階層
Olostep SDKは、さまざまな失敗シナリオに対応する包括的な例外階層を提供します。すべての例外はOlostep_BaseErrorから継承されます。
Olostep_BaseErrorから直接継承される3つの主要なエラータイプがあります:
Olostep_APIConnectionError- ネットワークレベルの接続失敗OlostepServerError_BaseError- APIサーバーによって発生するエラーOlostepClientError_BaseError- クライアントSDKによって発生するエラー
なぜ接続エラーが別なのか
Olostep_APIConnectionErrorは、ネットワークレベルの失敗を表すため、サーバーエラーとは別です。これらはトランスポートレイヤーの問題(DNSまたはHTTPの失敗、タイムアウト、接続拒否など)であり、APIレベルのエラーではありません。HTTPステータスコード(4xx、5xx)はAPI応答と見なされ、サーバーエラーとして分類されますが、問題を示しています。
推奨されるエラーハンドリング
ほとんどの使用ケースでは、ベースエラーをキャッチしてエラー名を表示します:OlostepServerError_AuthFailed)は、問題を理解するのに十分な説明です。
詳細なエラーハンドリング
より具体的なエラーハンドリングが必要な場合は、特定のエラータイプを直接キャッチします。OlostepServerError_BaseErrorまたはOlostepClientError_BaseErrorを使用しないでください - これらのベースクラスは、エラーを誰が発生させたか(サーバー対クライアント)を示すだけで、誰が修正する責任があるかを示しません。これはエラーハンドリングロジックには役立たない実装の詳細です。
代わりに、実際の問題を示す特定のエラータイプをキャッチします:
構成
環境変数
| 変数 | 説明 | デフォルト |
|---|---|---|
OLOSTEP_API_KEY | あなたのAPIキー | 必須 |
OLOSTEP_BASE_API_URL | APIベースURL | https://api.olostep.com/v1 |
OLOSTEP_API_TIMEOUT | リクエストタイムアウト(秒) | 150 |
ヘルプを得る
リソース
PyPIパッケージ
PyPIで表示
APIキーを取得
無料でサインアップ