Skip to main content
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.

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é.

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 : Chaque opération retourne des objets avec état et des méthodes ergonomiques pour les opérations de suivi.

Gestion des erreurs

Capturez toutes les erreurs SDK en utilisant la classe d’exception de base :
Pour des informations détaillées sur la gestion des erreurs, y compris la hiérarchie complète des exceptions et les options de gestion des erreurs granulaires, voir Gestion des erreurs détaillée.

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 configuration RetryStrategy. Vous pouvez personnaliser le comportement de reprise en passant une instance RetryStrategy lors de la création du client :
Pour des options de configuration détaillées de la reprise et des meilleures pratiques, voir Stratégie de reprise.

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 :
Niveaux de journalisation : INFO (recommandé), DEBUG (détaillé), WARNING, ERROR

Configuration de la stratégie de reprise

La classe RetryStrategy 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)
Cela signifie :
  • 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
Durée maximale : ~57 secondes pour toutes les reprises (cas le pire)

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)
Les autres erreurs (authentification, validation, ressource non trouvée, etc.) échouent immédiatement sans reprise.

Reprises de transport vs de l’appelant

Le SDK a deux couches de reprise :
  1. Couche de transport : Gère les échecs de connexion au niveau réseau (DNS, timeouts, etc.)
  2. Couche de l’appelant : Gère les erreurs transitoires au niveau de l’API (contrôlées par RetryStrategy)
Les deux couches sont indépendantes et ont une configuration séparée. La durée maximale totale est la somme des deux couches.

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 :
Par exemple, avec 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 :
Activez la journalisation de débogage pour surveiller le comportement de reprise :

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
Choisissez votre stratégie de reprise en fonction des exigences de votre application en matière de fiabilité par rapport aux performances.

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 de Olostep_BaseError. Il y a trois principaux types d’erreurs qui héritent directement de Olostep_BaseError :
  1. Olostep_APIConnectionError - Échecs de connexion au niveau réseau
  2. OlostepServerError_BaseError - Erreurs levées (en quelque sorte) par le serveur API
  3. OlostepClientError_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 :
Cette approche capture toutes les erreurs SDK et fournit des informations claires sur ce qui s’est mal passé. Le nom de l’erreur (par exemple, 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’utiliser OlostepServerError_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

Obtenir de l’aide

Ressources

Package PyPI

Voir sur PyPI

Obtenir une clé API

Inscrivez-vous gratuitement