Vai al contenuto principale
Pacchetto PyPI: olostep | Requisiti: Python 3.11+

Installazione

Autenticazione

Ottieni la tua chiave API dalla Dashboard di Olostep.

Inizio Rapido

L’SDK offre due opzioni di client a seconda del tuo caso d’uso:

Client Sincrono (`Olostep`)

Ideale per: Script e casi d’uso semplici dove preferisci operazioni bloccanti.

Il client sincrono fornisce un’interfaccia più semplice e bloccante che è più facile da iniziare se sei nuovo all’uso di async/await.

Client Asincrono (`AsyncOlostep`)

Ideale per: Applicazioni in produzione e gestione di molte richieste concorrenti.

Il client asincrono fornisce operazioni non bloccanti ed è la scelta consigliata per applicazioni in produzione che necessitano di un alto throughput.

Client Sincrono (Olostep)

Il client sincrono (Olostep) fornisce un’interfaccia bloccante perfetta per script e casi d’uso semplici.

Web Scraping di Base

Elaborazione in Batch

Smart Web Crawling

Site Mapping

Risposte Potenziate dall’AI

Client Asincrono (AsyncOlostep)

Il client asincrono (AsyncOlostep) è il client consigliato per applicazioni ad alte prestazioni, servizi backend e quando hai bisogno di gestire molte richieste concorrenti.

Web Scraping di Base

Elaborazione in Batch

Smart Web Crawling

Site Mapping

Risposte Potenziate dall’AI

Riferimento SDK

Struttura dei Metodi

Entrambi i client SDK forniscono la stessa interfaccia pulita e pythonica organizzata in namespace logici: Ogni operazione restituisce oggetti con stato con metodi ergonomici per operazioni successive.

Gestione degli Errori

Cattura tutti gli errori SDK utilizzando la classe di eccezione base:
Per informazioni dettagliate sulla gestione degli errori, inclusa la gerarchia completa delle eccezioni e le opzioni di gestione degli errori granulari, vedi Gestione Dettagliata degli Errori.

Riprovi Automatici

L’SDK riprova automaticamente in caso di errori transitori (problemi di rete, problemi temporanei del server) basandosi sulla configurazione di RetryStrategy. Puoi personalizzare il comportamento di riprova passando un’istanza di RetryStrategy quando crei il client:
Per opzioni di configurazione dettagliate sui riprovi e best practice, vedi Strategia di Riprova.

Funzionalità Avanzate

Coercizione Intelligente degli Input

L’SDK gestisce in modo intelligente vari formati di input per la massima comodità:

Opzioni Avanzate di Scraping

Caching

Per impostazione predefinita, ogni richiesta di scraping recupera la pagina fresca (max_age=0). Passa max_age per riutilizzare un risultato recente con gli stessi parametri e migliorare il tempo di risposta. Il valore è in secondi; il massimo è 7 giorni (604800). Vedi Caching per i dettagli.

Elaborazione in Batch con ID Personalizzati

Crawling Intelligente

Site Mapping con Filtri

Recupero delle Risposte

Recupero dei Contenuti

Logging

Abilita il logging per il debug dei problemi:
Livelli di Log: INFO (consigliato), DEBUG (verboso), WARNING, ERROR

Configurazione della Strategia di Riprova

La classe RetryStrategy controlla come l’SDK Olostep gestisce gli errori API transitori tramite riprovi automatici con backoff esponenziale e jitter. Questo aiuta a garantire un’operazione affidabile in ambienti di produzione dove problemi di rete temporanei, limiti di velocità e sovraccarico del server possono causare fallimenti intermittenti.

Comportamento Predefinito

Per impostazione predefinita, l’SDK utilizza la seguente configurazione di riprova:
  • Massimo di riprovi: 5 tentativi
  • Ritardo iniziale: 2 secondi
  • Backoff: Esponenziale (2^tentativo)
  • Jitter: 10-90% del ritardo (randomizzato)
Questo significa:
  • Tentativo 1: Immediato
  • Tentativo 2: ~2-3.6s di ritardo
  • Tentativo 3: ~4-7.2s di ritardo
  • Tentativo 4: ~8-14.4s di ritardo
  • Tentativo 5: ~16-28.8s di ritardo
Durata massima: ~57 secondi per tutti i riprovi (peggiore dei casi)

Configurazione Personalizzata

Quando Avvengono i Riprovi

L’SDK riprova automaticamente su:
  • Problemi temporanei del server (OlostepServerError_TemporaryIssue)
  • Risposte di timeout (OlostepServerError_NoResultInResponse)
Altri errori (autenticazione, validazione, risorsa non trovata, ecc.) falliscono immediatamente senza riprova.

Riprovi di Trasporto vs Chiamante

L’SDK ha due livelli di riprova:
  1. Livello di trasporto: Gestisce i fallimenti di connessione a livello di rete (DNS, timeout, ecc.)
  2. Livello di chiamante: Gestisce gli errori transitori a livello di API (controllato da RetryStrategy)
Entrambi i livelli sono indipendenti e hanno configurazioni separate. La durata massima totale è la somma di entrambi i livelli.

Calcolo della Durata Massima

Esempi di Configurazione

Ecco alcuni esempi su come configurare la strategia di riprova per diversi casi d’uso.

Strategia Conservativa

Strategia Aggressiva

Nessun Riprovo (Fallimento Immediato)

Strategia ad Alto Throughput

Comprendere il Jitter

Il jitter aggiunge randomizzazione per prevenire problemi di “thundering herd” quando molti client riprovano simultaneamente. Il jitter è calcolato come:
Ad esempio, con initial_delay=2.0, jitter_min=0.1, jitter_max=0.9:
  • Tentativo 0: base=2.0s, jitter=0.2-1.8s, finale=2.2-3.8s
  • Tentativo 1: base=4.0s, jitter=0.4-3.6s, finale=4.4-7.6s
  • Tentativo 2: base=8.0s, jitter=0.8-7.2s, finale=8.8-15.2s

Best Practices

Per Applicazioni in Produzione

Per Sviluppo/Test

Per Operazioni in Batch

Monitoraggio e Debugging

L’SDK registra le informazioni sui riprovi al livello DEBUG:
Abilita il logging di debug per monitorare il comportamento dei riprovi:

Gestione degli Errori

Quando tutti i riprovi sono esauriti, viene sollevato l’errore originale:

Considerazioni sulle Prestazioni

  • Memoria: Ogni tentativo di riprova utilizza memoria aggiuntiva per oggetti di richiesta/risposta
  • Tempo: Il tempo totale dell’operazione può essere significativamente più lungo con i riprovi abilitati
  • Limiti API: I riprovi contano contro i tuoi limiti di utilizzo API
  • Rete: Maggiore traffico di rete a causa dei tentativi di riprova
Scegli la tua strategia di riprova basandoti sui requisiti della tua applicazione per affidabilità vs. prestazioni.

Gestione Dettagliata degli Errori

Gerarchia delle Eccezioni

L’SDK Olostep fornisce una gerarchia di eccezioni completa per diversi scenari di fallimento. Tutte le eccezioni ereditano da Olostep_BaseError. Ci sono tre tipi principali di errori che ereditano direttamente da Olostep_BaseError:
  1. Olostep_APIConnectionError - Fallimenti di connessione a livello di rete
  2. OlostepServerError_BaseError - Errori sollevati (in qualche modo) dal server API
  3. OlostepClientError_BaseError - Errori sollevati dal client SDK

Perché gli Errori di Connessione Sono Separati

Olostep_APIConnectionError è separato dagli errori del server perché rappresenta fallimenti a livello di rete che si verificano prima che l’API possa elaborare la richiesta. Questi sono problemi a livello di trasporto (DNS o fallimenti HTTP, timeout, connessione rifiutata, ecc.) piuttosto che errori a livello di API. I codici di stato HTTP (4xx, 5xx) sono considerati risposte API e sono categorizzati come errori del server, anche se indicano problemi.

Gestione degli Errori Consigliata

Per la maggior parte dei casi d’uso, cattura l’errore base e stampa il nome dell’errore:
Questo approccio cattura tutti gli errori SDK e fornisce informazioni chiare su cosa è andato storto. Il nome dell’errore (es. OlostepServerError_AuthFailed) è sufficientemente descrittivo per comprendere il problema.

Gestione degli Errori Granulare

Se hai bisogno di una gestione degli errori più specifica, cattura direttamente i tipi di errore specifici. Evita di usare OlostepServerError_BaseError o OlostepClientError_BaseError - queste classi base indicano solo chi ha sollevato l’errore (server vs client), non chi è responsabile di risolverlo. Questo è un dettaglio di implementazione che non aiuta con la logica di gestione degli errori. Invece, cattura tipi di errore specifici che indicano il problema reale:

Configurazione

Variabili d’Ambiente

Ottenere Aiuto

Risorse

Pacchetto PyPI

Visualizza su PyPI

Ottieni Chiave API

Iscriviti gratuitamente