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: Produktivanwendungen und die Bearbeitung vieler gleichzeitiger Anfragen.
Der Async-Client bietet nicht-blockierende Operationen und ist die empfohlene Wahl für Produktivanwendungen, die hohen Durchsatz benötigen.
Der Async-Client bietet nicht-blockierende Operationen und ist die empfohlene Wahl für Produktivanwendungen, die hohen Durchsatz benötigen.
Sync Client (Olostep)
Der Sync-Client (Olostep) bietet eine blockierende Schnittstelle, die perfekt für Skripte und einfache Anwendungsfälle 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 die gleiche saubere, pythonische Schnittstelle, die in logische Namensräume organisiert ist:
Jede Operation gibt zustandsbehaftete Objekte mit ergonomischen Methoden für Folgeoperationen zurück.
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 Eingabekoerzierung
Das SDK verarbeitet intelligent verschiedene Eingabeformate für maximalen Komfort:Erweiterte Scraping-Optionen
Caching
Standardmäßig holt jede Scrape-Anfrage die Seite frisch ab (max_age=0). Gib max_age an, um ein kürzliches Ergebnis mit denselben Parametern wiederzuverwenden und die Antwortzeit zu verbessern. Der Wert ist in Sekunden; das Maximum beträgt 7 Tage (604800). Siehe Caching für Details.
Speicherung
Standardmäßig wird ein Scrape-Ergebnis etwa 7 Tage lang aufbewahrt. Gibstorage mit expires_in an, um es länger zu behalten: 10d, 30d, 60d, 90d, 180d, 365d oder never. Siehe Speicherung für Details.
Batch-Verarbeitung mit benutzerdefinierten IDs
Intelligentes Crawling
Site Mapping mit Filtern
Antworten abrufen
Inhaltsabruf
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 temporäre Netzwerkprobleme, Ratenbeschränkungen und Serverüberlastung 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übergehende Serverprobleme (
OlostepServerError_TemporaryIssue) - Timeout-Antworten (
OlostepServerError_NoResultInResponse)
Transport- vs. Anrufer-Wiederholungen
Das SDK hat zwei Wiederholungsebenen:- Transportebene: Behandelt netzwerkbezogene Verbindungsfehler (DNS, Timeouts, etc.)
- Anrufer-Ebene: Behandelt API-bezogene vorübergehende Fehler (gesteuert durch
RetryStrategy)
Berechnung der maximalen Dauer
Konfigurationsbeispiele
Hier sind einige Beispiele, wie du die Wiederholungsstrategie für verschiedene Anwendungsfälle konfigurieren kannst.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 vermeiden, wenn viele Clients gleichzeitig wiederholen. Der Jitter wird berechnet als:initial_delay=2.0, jitter_min=0.1, jitter_max=0.9:
- Versuch 0: base=2.0s, jitter=0.2-1.8s, final=2.2-3.8s
- Versuch 1: base=4.0s, jitter=0.4-3.6s, final=4.4-7.6s
- Versuch 2: base=8.0s, jitter=0.8-7.2s, final=8.8-15.2s
Best Practices
Für Produktivanwendungen
Für Entwicklung/Testen
Für Batch-Operationen
Überwachung und Debugging
Das SDK protokolliert Wiederholungsinformationen auf 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 Anfrage-/Antwortobjekte
- Zeit: Die gesamte Betriebszeit 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- Netzwerkebene 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 netzwerkbezogene Fehler darstellt, die auftreten, bevor die API die Anfrage verarbeiten kann. Dies sind Transportebenenprobleme (DNS- oder HTTP-Fehler, Timeouts, Verbindung verweigert usw.) 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 gib den Fehlernamen aus:OlostepServerError_AuthFailed) ist aussagekräftig genug, 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
Hilfe erhalten
Ressourcen
PyPI-Paket
Auf PyPI ansehen
API-Schlüssel erhalten
Kostenlos anmelden