Paquet PyPI : olostep | Exigences : Python 3.11+
Installation
Authentification
Obtiens ta clé API depuis le Tableau de bord Olostep.Démarrage rapide
Le SDK propose deux options de client selon ton cas d’utilisation :Client Synchrone (Olostep)
Idéal pour : Scripts et cas d’utilisation simples où tu préfères des opérations bloquantes.
Le client synchrone offre une interface plus simple et bloquante, plus facile à utiliser si tu es nouveau dans l’async/await.
Le client synchrone offre une interface plus simple et bloquante, plus facile à utiliser si tu es nouveau dans l’async/await.
Client Asynchrone (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 Synchrone (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 Asynchrone (AsyncOlostep)
Le client asynchrone (AsyncOlostep) est le client recommandé pour les applications à haute performance, les services backend, et lorsque tu dois 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 propre et pythonique organisée en espaces de noms logiques :
Chaque opération renvoie des objets avec état dotés de méthodes ergonomiques pour les opérations de suivi.
Gestion des erreurs
Capture toutes les erreurs 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. Tu peux 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 un maximum de commodité :Options avancées d’extraction
Mise en cache
Par défaut, chaque requête d’extraction récupère la page fraîche (max_age=0). Passe max_age pour réutiliser un résultat récent avec les mêmes paramètres et améliorer le temps de réponse. La valeur est en secondes ; le maximum est de 7 jours (604800). Voir Mise en cache pour plus de détails.
Stockage
Par défaut, un résultat d’extraction est conservé environ 7 jours. Passestorage avec expires_in défini à 10d, 30d, 60d, 90d, 180d, 365d, ou never pour le conserver plus longtemps. Voir Stockage pour plus de détails.
Traitement par lots avec IDs personnalisés
Exploration intelligente
Cartographie du site avec filtres
Récupération des réponses
Récupération de contenu
Journalisation
Active 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 à assurer 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 causer 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 délai d’attente (
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, délais d’attente, 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 “troupeau tonitruant” 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 d’origine 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 dans tes 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 d’exceptions complète pour différents scénarios d’échec. Toutes les exceptions héritent deOlostep_BaseError.
Il y a trois principaux types d’erreurs qui héritent directement de Olostep_BaseError :
Olostep_APIConnectionError- Échecs de connexion au niveau du réseauOlostepServerError_BaseError- Erreurs levées (en quelque sorte) par le serveur APIOlostepClientError_BaseError- Erreurs levées par le SDK client
Pourquoi les erreurs de connexion sont séparées
Olostep_APIConnectionError est séparé des erreurs de 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, délais d’attente, 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 erreurs de serveur, même s’ils indiquent des problèmes.
Gestion des erreurs recommandée
Pour la plupart des cas d’utilisation, capture l’erreur de base et affiche le nom de l’erreur :OlostepServerError_AuthFailed) est suffisamment descriptif pour comprendre le problème.
Gestion des erreurs granulaires
Si tu as besoin d’une gestion des erreurs plus spécifique, capture directement les types d’erreurs spécifiques. Évite d’utiliserOlostepServerError_BaseError ou OlostepClientError_BaseError - ces classes de base indiquent seulement qui a levé l’erreur (serveur vs client), pas qui est responsable de la résoudre. C’est un détail d’implémentation qui n’aide pas avec la logique de gestion des erreurs.
Au lieu de cela, capture les types d’erreurs spécifiques qui indiquent le problème réel :
Configuration
Variables d’environnement
Obtenir de l’aide
Ressources
Paquet PyPI
Voir sur PyPI
Obtenir une clé API
Inscris-toi gratuitement