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 Verarbeitung vieler gleichzeitiger Anfragen.
Der Async-Client bietet nicht-blockierende Operationen und ist die empfohlene Wahl für Produktionsanwendungen, die hohe Durchsätze benötigen.
Der Async-Client bietet nicht-blockierende Operationen und ist die empfohlene Wahl für Produktionsanwendungen, die hohe Durchsätze 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 verarbeiten 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:| 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-gestützte Extraktion | create(), get() |
retrieve | Inhaltsabruf | get() |
Fehlerbehandlung
Fange alle SDK-Fehler mit der Basisklasse der Ausnahmen: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
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.
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, Ratenlimits 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 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: Handhabt netzwerkbezogene Verbindungsfehler (DNS, Timeouts, etc.)
- Anrufer-Schicht: Handhabt 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)
Strategie für hohen Durchsatz
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, End=2.2-3.8s
- Versuch 1: Basis=4.0s, Jitter=0.4-3.6s, End=4.4-7.6s
- Versuch 2: Basis=8.0s, Jitter=0.8-7.2s, End=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 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 Hauptfehlerarten, 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 netzwerkbezogene Fehler darstellt, 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 den Basisfehler 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
| 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 | Anforderungszeitlimit (Sekunden) | 150 |
Hilfe erhalten
Ressourcen
PyPI-Paket
Auf PyPI ansehen
API-Schlüssel erhalten
Kostenlos anmelden