Package 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 sync offre une interface plus simple et bloquante, plus facile à utiliser si vous êtes nouveau dans l’async/await.
Le client sync offre une interface plus simple et bloquante, plus facile à utiliser si vous êtes nouveau dans l’async/await.
Client Async (`AsyncOlostep`)
Idéal pour : Applications en production et gestion de nombreuses requêtes simultanées.
Le client async offre des opérations non bloquantes et est le choix recommandé pour les applications en production nécessitant un débit élevé.
Le client async 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 sync (Olostep) offre une interface bloquante parfaite pour les scripts et les cas d’utilisation simples.
Scraping Web de base
Traitement par lot
Crawling Web intelligent
Cartographie du site
Réponses alimentées par l’IA
Client Async (AsyncOlostep)
Le client async (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.
Scraping Web de base
Traitement par lot
Crawling Web intelligent
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
Capturez toutes les erreurs SDK en utilisant la classe d’exception de base :Reprises 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 reprise en passant une instance 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 de scraping avancées
Mise en cache
Par défaut, chaque requête de scraping récupère la page fraîche (max_age=0). Passez 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 les détails.
Traitement par lot avec IDs personnalisés
Crawling intelligent
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 reprise
La classeRetryStrategy contrôle comment le SDK Olostep gère les erreurs API transitoires via des reprises automatiques avec backoff exponentiel et jitter. Cela aide à assurer une opération 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 reprise suivante :- Reprises 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 reprises se produisent
Le SDK réessaie automatiquement en cas de :- Problèmes temporaires du serveur (
OlostepServerError_TemporaryIssue) - Réponses de timeout (
OlostepServerError_NoResultInResponse)
Reprises de transport vs de l’appelant
Le SDK a deux couches de reprise :- Couche de transport : Gère les échecs de connexion au niveau 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 reprise pour différents cas d’utilisation.Stratégie conservatrice
Stratégie agressive
Pas de reprises (é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 lot
Surveillance et débogage
Le SDK journalise les informations de reprise au niveau DEBUG :Gestion des erreurs
Lorsque toutes les reprises sont épuisées, l’erreur d’origine est levée :Considérations sur les performances
- Mémoire : Chaque tentative de reprise 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 reprises activées
- Limites API : Les reprises comptent contre vos limites d’utilisation de l’API
- Réseau : Plus de trafic réseau en raison des tentatives de reprise
Gestion des erreurs détaillée
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 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 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 de l’API et sont catégorisés comme des erreurs de serveur, même s’ils indiquent des problèmes.
Gestion des erreurs recommandée
Pour la plupart des cas d’utilisation, capturez l’erreur de base et imprimez 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, capturez directement les types d’erreurs spécifiques. Évitez d’utiliserOlostepServerError_BaseError ou OlostepClientError_BaseError - ces classes de base n’indiquent que qui a levé l’erreur (serveur vs client), pas qui est responsable de la corriger. C’est un détail d’implémentation qui n’aide pas avec la logique de gestion des erreurs.
Au lieu de cela, capturez les types d’erreurs spécifiques qui indiquent le problème réel :
Configuration
Variables d’environnement
| Variable | Description | 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 la requête (secondes) | 150 |
Obtenir de l’aide
Ressources
Package PyPI
Voir sur PyPI
Obtenir une clé API
Inscrivez-vous gratuitement