PyPI-Paket: olostep | Anforderungen: Python 3.11+
Installation
Authentifizierung
Hole dir deinen API-Schlüssel vom Olostep Dashboard.Schnellstart
Das SDK bietet zwei Client-Optionen, je nach Anwendungsfall:Sync-Client (`Olostep`)
Am besten geeignet für: Skripte und einfache Anwendungsfälle, bei denen du blockierende Operationen bevorzugst.
Der Sync-Client bietet eine einfachere, blockierende Schnittstelle, die leichter zu verwenden ist, wenn du neu bei async/await bist.
Der Sync-Client bietet eine einfachere, blockierende Schnittstelle, die leichter zu verwenden ist, wenn du neu bei async/await bist.
Async-Client (`AsyncOlostep`)
Am besten geeignet für: Produktionsanwendungen und die Bearbeitung vieler gleichzeitiger Anfragen.
Der Async-Client bietet nicht-blockierende Operationen und ist die empfohlene Wahl für Produktionsanwendungen, die eine hohe Durchsatzrate benötigen.
Der Async-Client bietet nicht-blockierende Operationen und ist die empfohlene Wahl für Produktionsanwendungen, die eine hohe Durchsatzrate benötigen.
Sync-Client (Olostep)
Der Sync-Client (Olostep) bietet eine blockierende Schnittstelle, die perfekt für Skripte und einfache Anwendungsfälle geeignet ist.
Einfaches Web Scraping
Batch-Verarbeitung
Intelligentes Web Crawling
Site-Mapping
KI-gestützte Antworten
Async-Client (AsyncOlostep)
Der Async-Client (AsyncOlostep) ist der empfohlene Client für Hochleistungsanwendungen, Backend-Dienste und wenn du viele gleichzeitige Anfragen bearbeiten musst.
Einfaches Web Scraping
Batch-Verarbeitung
Intelligentes Web Crawling
Site-Mapping
KI-gestützte Antworten
SDK-Referenz
Methodenstruktur
Beide SDK-Clients bieten dieselbe saubere, pythonische Schnittstelle, die in logische Namensräume organisiert ist:| Namensraum | Zweck | Wichtige Methoden |
|---|---|---|
scrapes | Einzel-URL-Extraktion | create(), get() |
batches | Multi-URL-Verarbeitung | create(), info(), items() |
crawls | Website-Durchquerung | create(), info(), pages() |
maps | Link-Extraktion | create(), urls() |
answers | KI-gestützte Extraktion | create(), get() |
retrieve | Inhaltserfassung | get() |
Fehlerbehandlung
Fange alle SDK-Fehler mit der Basisausnahmeklasse ab:Automatische Wiederholungen
Das SDK wiederholt automatisch bei vorübergehenden Fehlern (Netzwerkprobleme, temporäre Serverprobleme) basierend auf derRetryStrategy-Konfiguration. Du kannst das Wiederholungsverhalten anpassen, indem du eine RetryStrategy-Instanz beim Erstellen des Clients übergibst:
Erweiterte Funktionen
Intelligente Eingabekonvertierung
Das SDK verarbeitet intelligent verschiedene Eingabeformate für maximalen Komfort:Erweiterte Scraping-Optionen
Batch-Verarbeitung mit benutzerdefinierten IDs
Intelligentes Crawling
Site-Mapping mit Filtern
Antwortabruf
Inhaltserfassung
Logging
Aktiviere Logging, um Probleme zu debuggen:INFO (empfohlen), DEBUG (ausführlich), WARNING, ERROR
Konfiguration der Wiederholungsstrategie
DieRetryStrategy-Klasse steuert, wie das Olostep SDK vorübergehende API-Fehler durch automatische Wiederholungen mit exponentiellem Backoff und Jitter behandelt. Dies hilft, einen zuverlässigen Betrieb in Produktionsumgebungen sicherzustellen, in denen vorübergehende Netzwerkprobleme, Ratenbeschränkungen und Serverüberlastungen zu intermittierenden Ausfällen führen können.
Standardverhalten
Standardmäßig verwendet das SDK die folgende Wiederholungskonfiguration:- Maximale Wiederholungen: 5 Versuche
- Anfängliche Verzögerung: 2 Sekunden
- Backoff: Exponentiell (2^Versuch)
- Jitter: 10-90% der Verzögerung (zufällig)
- Versuch 1: Sofort
- Versuch 2: ~2-3,6s Verzögerung
- Versuch 3: ~4-7,2s Verzögerung
- Versuch 4: ~8-14,4s Verzögerung
- Versuch 5: ~16-28,8s Verzögerung
Benutzerdefinierte Konfiguration
Wann Wiederholungen stattfinden
Das SDK wiederholt automatisch bei:- Vorübergehenden Serverproblemen (
OlostepServerError_TemporaryIssue) - Timeout-Antworten (
OlostepServerError_NoResultInResponse)
Transport- vs. Anrufer-Wiederholungen
Das SDK hat zwei Wiederholungsebenen:- Transportschicht: Behandelt netzwerkbezogene Verbindungsfehler (DNS, Timeouts, etc.)
- Anruferschicht: Behandelt API-bezogene vorübergehende Fehler (gesteuert durch
RetryStrategy)
Berechnung der maximalen Dauer
Konfigurationsbeispiele
Hier sind einige Beispiele, wie die Wiederholungsstrategie für verschiedene Anwendungsfälle konfiguriert werden kann.Konservative Strategie
Aggressive Strategie
Keine Wiederholungen (schnelles Scheitern)
Hochdurchsatzstrategie
Verständnis von Jitter
Jitter fügt eine Zufälligkeit hinzu, um “thundering herd”-Probleme zu verhindern, wenn viele Clients gleichzeitig wiederholen. Der Jitter wird wie folgt berechnet:initial_delay=2.0, jitter_min=0.1, jitter_max=0.9:
- Versuch 0: Basis=2.0s, Jitter=0.2-1.8s, final=2.2-3.8s
- Versuch 1: Basis=4.0s, Jitter=0.4-3.6s, final=4.4-7.6s
- Versuch 2: Basis=8.0s, Jitter=0.8-7.2s, final=8.8-15.2s
Beste Praktiken
Für Produktionsanwendungen
Für Entwicklung/Test
Für Batch-Operationen
Überwachung und Debugging
Das SDK protokolliert Wiederholungsinformationen auf der DEBUG-Ebene:Fehlerbehandlung
Wenn alle Wiederholungen erschöpft sind, wird der ursprüngliche Fehler ausgelöst:Leistungsüberlegungen
- Speicher: Jeder Wiederholungsversuch verwendet zusätzlichen Speicher für Anforderungs-/Antwortobjekte
- Zeit: Die gesamte Operationszeit kann mit aktivierten Wiederholungen erheblich länger sein
- API-Limits: Wiederholungen zählen gegen deine API-Nutzungslimits
- Netzwerk: Mehr Netzwerkverkehr aufgrund von Wiederholungsversuchen
Detaillierte Fehlerbehandlung
Ausnahmehierarchie
Das Olostep SDK bietet eine umfassende Ausnahmehierarchie für verschiedene Fehlerszenarien. Alle Ausnahmen erben vonOlostep_BaseError.
Es gibt drei Hauptfehlertypen, die direkt von Olostep_BaseError erben:
Olostep_APIConnectionError- Netzwerkbezogene VerbindungsfehlerOlostepServerError_BaseError- Fehler, die (irgendwie) vom API-Server ausgelöst werdenOlostepClientError_BaseError- Fehler, die vom Client-SDK ausgelöst werden
Warum Verbindungsfehler separat sind
Olostep_APIConnectionError ist von Serverfehlern getrennt, da es sich um netzwerkbezogene Fehler handelt, die auftreten, bevor die API die Anfrage verarbeiten kann. Dies sind Transportebenenprobleme (DNS- oder HTTP-Fehler, Timeouts, Verbindung verweigert, etc.) und keine API-Ebene-Fehler. HTTP-Statuscodes (4xx, 5xx) werden als API-Antworten betrachtet und als Serverfehler kategorisiert, auch wenn sie Probleme anzeigen.
Empfohlene Fehlerbehandlung
Für die meisten Anwendungsfälle, fange die Basisausnahme ab und drucke den Fehlernamen:OlostepServerError_AuthFailed) ist ausreichend beschreibend, um das Problem zu verstehen.
Granulare Fehlerbehandlung
Wenn du eine spezifischere Fehlerbehandlung benötigst, fange die spezifischen Fehlertypen direkt ab. Vermeide die Verwendung vonOlostepServerError_BaseError oder OlostepClientError_BaseError - diese Basisklassen zeigen nur an, wer den Fehler ausgelöst hat (Server vs. Client), nicht wer für die Behebung verantwortlich ist. Dies ist ein Implementierungsdetail, das bei der Fehlerbehandlungslogik nicht hilft.
Stattdessen, fange spezifische Fehlertypen ab, die das tatsächliche Problem anzeigen:
Konfiguration
Umgebungsvariablen
| Variable | Beschreibung | Standard |
|---|---|---|
OLOSTEP_API_KEY | Dein API-Schlüssel | Erforderlich |
OLOSTEP_BASE_API_URL | API-Basis-URL | https://api.olostep.com/v1 |
OLOSTEP_API_TIMEOUT | Anforderungs-Timeout (Sek.) | 150 |
Hilfe erhalten
Ressourcen
PyPI-Paket
Auf PyPI ansehen
API-Schlüssel erhalten
Kostenlos registrieren