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 novice en async/await.
Le client synchrone offre une interface plus simple et bloquante, plus facile à utiliser si tu es novice en 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 Basique
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 Basique
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’une URL | 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
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
Traitement par Lots avec Identifiants Personnalisés
Exploration Intelligente
Cartographie du Site avec Filtres
Récupération de 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 un backoff exponentiel et un 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 réseau (DNS, délais d’attente, etc.)
- Couche d’appelant : Gère les erreurs transitoires au niveau API (contrôlé par
RetryStrategy)
Calcul de la Durée Max
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 enregistre 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 de Performance
- 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 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 existe 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 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, délais d’attente, connexion refusée, etc.) plutôt que des erreurs au niveau API. Les codes de statut HTTP (4xx, 5xx) sont considérés comme des réponses API et sont classés comme erreurs 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 Granulaire des Erreurs
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 corriger. C’est un détail d’implémentation qui n’aide pas à 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
| Variable | Description | Par défaut |
|---|---|---|
OLOSTEP_API_KEY | Ta clé API | Requise |
OLOSTEP_BASE_API_URL | URL de base de l’API | https://api.olostep.com/v1 |
OLOSTEP_API_TIMEOUT | Délai d’attente de la requête (secondes) | 150 |
Obtenir de l’Aide
Ressources
Paquet PyPI
Voir sur PyPI
Obtenir une Clé API
Inscris-toi gratuitement