PyPI-Paket: olostep | Anforderungen: Python 3.11+
Installation
Authentifizierung
Holen Sie sich Ihren 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 Sie blockierende Operationen bevorzugen.
Der Sync-Client bietet eine einfachere, blockierende Schnittstelle, die einfacher zu starten ist, wenn Sie neu bei async/await sind.
Der Sync-Client bietet eine einfachere, blockierende Schnittstelle, die einfacher zu starten ist, wenn Sie neu bei async/await sind.
Async Client (`AsyncOlostep`)
Am besten geeignet für: Produktionsanwendungen und die Handhabung vieler gleichzeitiger Anfragen.
Der Async-Client bietet nicht-blockierende Operationen und ist die empfohlene Wahl für Produktionsanwendungen, die einen hohen Durchsatz benötigen.
Der Async-Client bietet nicht-blockierende Operationen und ist die empfohlene Wahl für Produktionsanwendungen, die einen 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-gesteuerte Antworten
Async Client (AsyncOlostep)
Der Async-Client (AsyncOlostep) ist der empfohlene Client für Hochleistungsanwendungen, Backend-Dienste und wenn Sie viele gleichzeitige Anfragen bearbeiten müssen.
Einfaches Web Scraping
Batch-Verarbeitung
Intelligentes Web Crawling
Site Mapping
KI-gesteuerte Antworten
SDK-Referenz
Methodensystematik
Beide SDK-Clients bieten die gleiche saubere, pythonische Schnittstelle, die in logische Namensräume organisiert ist:| Namensraum | Zweck | Schlüsselmethoden |
|---|---|---|
scrapes | Einzel-URL-Extraktion | create(), get() |
batches | Multi-URL-Verarbeitung | create(), info(), items() |
crawls | Website-Durchlauf | create(), info(), pages() |
maps | Link-Extraktion | create(), urls() |
answers | KI-gesteuerte Extraktion | create(), get() |
retrieve | Inhaltsabruf | get() |
Fehlerbehandlung
Fangen Sie alle SDK-Fehler mit der Basisklasse der Ausnahmen ab:Automatische Wiederholungen
Das SDK wiederholt automatisch bei vorübergehenden Fehlern (Netzwerkprobleme, temporäre Serverprobleme) basierend auf derRetryStrategy-Konfiguration. Sie können das Wiederholungsverhalten anpassen, indem Sie eine RetryStrategy-Instanz beim Erstellen des Clients übergeben:
Erweiterte Funktionen
Intelligente Eingabekonvertierung
Das SDK verarbeitet verschiedene Eingabeformate intelligent für maximalen Komfort:Erweiterte Scraping-Optionen
Batch-Verarbeitung mit benutzerdefinierten IDs
Intelligentes Crawling
Site Mapping mit Filtern
Antworten abrufen
Inhaltsabruf
Protokollierung
Aktivieren Sie die Protokollierung, 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überlastungen zu intermittierenden Fehlern 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 auftreten
Das SDK wiederholt automatisch bei:- Vorübergehenden Serverproblemen (
OlostepServerError_TemporaryIssue) - Timeout-Antworten (
OlostepServerError_NoResultInResponse)
Transport- vs. Anrufer-Wiederholungen
Das SDK hat zwei Wiederholungsebenen:- Transportebene: Handhabt netzwerkbezogene Verbindungsfehler (DNS, Timeouts, etc.)
- Anruferebene: Handhabt API-bezogene vorübergehende Fehler (gesteuert durch
RetryStrategy)
Berechnung der maximalen Dauer
Konfigurationsbeispiele
Hier sind einige Beispiele, wie Sie die Wiederholungsstrategie für verschiedene Anwendungsfälle konfigurieren können.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
Best Practices
Für Produktionsanwendungen
Für Entwicklung/Test
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 Anforderungs-/Antwortobjekte
- Zeit: Die Gesamtbetriebszeit kann mit aktivierten Wiederholungen erheblich länger sein
- API-Limits: Wiederholungen zählen gegen Ihre 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 fangen Sie den Basisfehler ab und drucken den Fehlernamen:OlostepServerError_AuthFailed) ist beschreibend genug, um das Problem zu verstehen.
Granulare Fehlerbehandlung
Wenn Sie eine spezifischere Fehlerbehandlung benötigen, fangen Sie die spezifischen Fehlertypen direkt ab. Vermeiden Sie 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 fangen Sie spezifische Fehlertypen ab, die das tatsächliche Problem anzeigen:
Konfiguration
Umgebungsvariablen
| Variable | Beschreibung | Standard |
|---|---|---|
OLOSTEP_API_KEY | Ihr API-Schlüssel | Erforderlich |
OLOSTEP_BASE_API_URL | API-Basis-URL | https://api.olostep.com/v1 |
OLOSTEP_API_TIMEOUT | Anforderungs-Timeout (Sekunden) | 150 |
Hilfe erhalten
Ressourcen
PyPI-Paket
Auf PyPI ansehen
API-Schlüssel erhalten
Kostenlos anmelden