Passer au contenu principal
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.

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

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 :
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 détaillée des erreurs.

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

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

Configuration de la stratégie de réessai

La classe RetryStrategy 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)
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 tous les réessais (pire cas)

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

Réessais de transport vs appelant

Le SDK a deux couches de réessai :
  1. Couche de transport : Gère les échecs de connexion au niveau du réseau (DNS, délais d’attente, 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 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 :
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 lots

Surveillance et débogage

Le SDK journalise les informations de réessai au niveau DEBUG :
Active la journalisation de débogage pour surveiller le comportement des réessais :

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
Choisis ta stratégie de réessai en fonction des exigences de ton application en matière de fiabilité vs. performance.

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 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 du 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 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 :
Cette approche capture toutes les erreurs SDK et fournit des informations claires sur ce qui a mal tourné. Le nom de l’erreur (par exemple, 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’utiliser OlostepServerError_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