Paquet PyPI: olostep | Exigences: Python 3.11+
Installation
Authentification
Obtenez votre clé API depuis le Tableau de bord Olostep.Démarrage rapide
Le SDK propose deux options de client selon votre cas d’utilisation :Client Sync (`Olostep`)
Idéal pour : Scripts et cas d’utilisation simples où vous préférez des opérations bloquantes.
Le client synchrone offre une interface plus simple et bloquante, plus facile à utiliser si vous débutez avec async/await.
Le client synchrone offre une interface plus simple et bloquante, plus facile à utiliser si vous débutez avec async/await.
Client Async (`AsyncOlostep`)
Idéal pour : Applications en production, et gestion de nombreuses requêtes simultanées.
Le client asynchrone offre des opérations non bloquantes et est le choix recommandé pour les applications en production nécessitant un débit élevé.
Le client asynchrone offre des opérations non bloquantes et est le choix recommandé pour les applications en production nécessitant un débit élevé.
Client Sync (Olostep)
Le client synchrone (Olostep) offre une interface bloquante parfaite pour les scripts et les cas d’utilisation simples.
Extraction Web de base
Traitement par lots
Exploration Web intelligente
Cartographie du site
Réponses alimentées par l’IA
Client Async (AsyncOlostep)
Le client asynchrone (AsyncOlostep) est le client recommandé pour les applications haute performance, les services backend, et lorsque vous devez gérer de nombreuses requêtes simultanées.
Extraction Web de base
Traitement par lots
Exploration Web intelligente
Cartographie du site
Réponses alimentées par l’IA
Référence SDK
Structure des méthodes
Les deux clients SDK offrent la même interface claire et pythonique organisée en espaces de noms logiques :| Espace de noms | Objectif | Méthodes clés |
|---|---|---|
scrapes | Extraction d’URL unique | create(), get() |
batches | Traitement multi-URL | create(), info(), items() |
crawls | Parcours de site web | create(), info(), pages() |
maps | Extraction de liens | create(), urls() |
answers | Extraction alimentée par l’IA | create(), get() |
retrieve | Récupération de contenu | get() |
Gestion des erreurs
Interceptez toutes les erreurs du SDK en utilisant la classe d’exception de base :Réessais automatiques
Le SDK réessaie automatiquement en cas d’erreurs transitoires (problèmes de réseau, problèmes temporaires du serveur) en fonction de la configurationRetryStrategy. Vous pouvez personnaliser le comportement de réessai en passant une instance de RetryStrategy lors de la création du client :
Fonctionnalités avancées
Coercition intelligente des entrées
Le SDK gère intelligemment divers formats d’entrée pour une commodité maximale :Options avancées d’extraction
Traitement par lots avec ID personnalisés
Exploration intelligente
Cartographie du site avec filtres
Récupération des réponses
Récupération de contenu
Journalisation
Activez la journalisation pour déboguer les problèmes :INFO (recommandé), DEBUG (détaillé), WARNING, ERROR
Configuration de la stratégie de réessai
La classeRetryStrategy contrôle comment le SDK Olostep gère les erreurs API transitoires via des réessais automatiques avec backoff exponentiel et jitter. Cela aide à garantir un fonctionnement fiable dans les environnements de production où des problèmes de réseau temporaires, des limites de taux et une surcharge du serveur peuvent provoquer des échecs intermittents.
Comportement par défaut
Par défaut, le SDK utilise la configuration de réessai suivante :- Réessais max : 5 tentatives
- Délai initial : 2 secondes
- Backoff : Exponentiel (2^tentative)
- Jitter : 10-90% du délai (aléatoire)
- Tentative 1 : Immédiate
- Tentative 2 : ~2-3.6s de délai
- Tentative 3 : ~4-7.2s de délai
- Tentative 4 : ~8-14.4s de délai
- Tentative 5 : ~16-28.8s de délai
Configuration personnalisée
Quand les réessais se produisent
Le SDK réessaie automatiquement en cas de :- Problèmes temporaires du serveur (
OlostepServerError_TemporaryIssue) - Réponses de timeout (
OlostepServerError_NoResultInResponse)
Réessais de transport vs appelant
Le SDK a deux couches de réessai :- Couche de transport : Gère les échecs de connexion au niveau du réseau (DNS, timeouts, etc.)
- Couche de l’appelant : Gère les erreurs transitoires au niveau de l’API (contrôlées par
RetryStrategy)
Calcul de la durée maximale
Exemples de configuration
Voici quelques exemples de configuration de la stratégie de réessai pour différents cas d’utilisation.Stratégie conservatrice
Stratégie agressive
Pas de réessais (échec rapide)
Stratégie à haut débit
Comprendre le Jitter
Le jitter ajoute une randomisation pour éviter les problèmes de “thundering herd” lorsque de nombreux clients réessaient simultanément. Le jitter est calculé comme suit :initial_delay=2.0, jitter_min=0.1, jitter_max=0.9 :
- Tentative 0 : base=2.0s, jitter=0.2-1.8s, final=2.2-3.8s
- Tentative 1 : base=4.0s, jitter=0.4-3.6s, final=4.4-7.6s
- Tentative 2 : base=8.0s, jitter=0.8-7.2s, final=8.8-15.2s
Meilleures pratiques
Pour les applications en production
Pour le développement/test
Pour les opérations par lots
Surveillance et débogage
Le SDK journalise les informations de réessai au niveau DEBUG :Gestion des erreurs
Lorsque tous les réessais sont épuisés, l’erreur originale est levée :Considérations sur les performances
- Mémoire : Chaque tentative de réessai utilise de la mémoire supplémentaire pour les objets de requête/réponse
- Temps : Le temps total de l’opération peut être significativement plus long avec les réessais activés
- Limites API : Les réessais comptent contre vos limites d’utilisation de l’API
- Réseau : Plus de trafic réseau en raison des tentatives de réessai
Gestion détaillée des erreurs
Hiérarchie des exceptions
Le SDK Olostep fournit une hiérarchie complète d’exceptions pour différents scénarios d’échec. Toutes les exceptions héritent deOlostep_BaseError.
Il existe trois principaux types d’erreurs qui héritent directement de Olostep_BaseError :
Olostep_APIConnectionError- Échecs de connexion au niveau du réseauOlostepServerError_BaseError- Erreurs soulevées (en quelque sorte) par le serveur APIOlostepClientError_BaseError- Erreurs soulevées par le SDK client
Pourquoi les erreurs de connexion sont séparées
Olostep_APIConnectionError est séparé des erreurs serveur car il représente des échecs au niveau du réseau qui se produisent avant que l’API puisse traiter la requête. Ce sont des problèmes de couche de transport (échecs DNS ou HTTP, timeouts, connexion refusée, etc.) plutôt que des erreurs au niveau de l’API. Les codes d’état HTTP (4xx, 5xx) sont considérés comme des réponses API et sont classés comme des erreurs serveur, même s’ils indiquent des problèmes.
Gestion des erreurs recommandée
Pour la plupart des cas d’utilisation, interceptez l’erreur de base et affichez le nom de l’erreur :OlostepServerError_AuthFailed) est suffisamment descriptif pour comprendre le problème.
Gestion des erreurs granulaires
Si vous avez besoin d’une gestion des erreurs plus spécifique, interceptez directement les types d’erreurs spécifiques. Évitez d’utiliserOlostepServerError_BaseError ou OlostepClientError_BaseError - ces classes de base indiquent seulement qui a soulevé l’erreur (serveur vs client), pas qui est responsable de la corriger. C’est un détail d’implémentation qui n’aide pas à la logique de gestion des erreurs.
Au lieu de cela, interceptez les types d’erreurs spécifiques qui indiquent le problème réel :
Configuration
Variables d’environnement
| Variable | Description | Par défaut |
|---|---|---|
OLOSTEP_API_KEY | Votre clé API | Requis |
OLOSTEP_BASE_API_URL | URL de base de l’API | https://api.olostep.com/v1 |
OLOSTEP_API_TIMEOUT | Timeout de requête (secondes) | 150 |