Skip to main content
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.

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.

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: Jede Operation gibt zustandsbehaftete Objekte mit ergonomischen Methoden für Folgeoperationen zurück.

Fehlerbehandlung

Fange alle SDK-Fehler mit der Basisklasse der Ausnahmen:
Für detaillierte Informationen zur Fehlerbehandlung, einschließlich der vollständigen Ausnahmehierarchie und granularer Fehlerbehandlungsoptionen, siehe Detaillierte Fehlerbehandlung.

Automatische Wiederholungen

Das SDK wiederholt automatisch bei vorübergehenden Fehlern (Netzwerkprobleme, temporäre Serverprobleme) basierend auf der RetryStrategy-Konfiguration. Du kannst das Wiederholungsverhalten anpassen, indem du eine RetryStrategy-Instanz beim Erstellen des Clients übergibst:
Für detaillierte Optionen zur Wiederholungskonfiguration und bewährte Praktiken siehe Retry Strategy.

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:
Log-Level: INFO (empfohlen), DEBUG (ausführlich), WARNING, ERROR

Konfiguration der Wiederholungsstrategie

Die RetryStrategy-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)
Das bedeutet:
  • 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
Maximale Dauer: ~57 Sekunden für alle Wiederholungen (schlechtester Fall)

Benutzerdefinierte Konfiguration

Wann Wiederholungen stattfinden

Das SDK wiederholt automatisch bei:
  • Vorübergehenden Serverproblemen (OlostepServerError_TemporaryIssue)
  • Timeout-Antworten (OlostepServerError_NoResultInResponse)
Andere Fehler (Authentifizierung, Validierung, Ressource nicht gefunden, etc.) schlagen sofort ohne Wiederholung fehl.

Transport- vs. Anrufer-Wiederholungen

Das SDK hat zwei Wiederholungsebenen:
  1. Transportschicht: Handhabt netzwerkbezogene Verbindungsfehler (DNS, Timeouts, etc.)
  2. Anrufer-Schicht: Handhabt API-bezogene vorübergehende Fehler (gesteuert durch RetryStrategy)
Beide Ebenen sind unabhängig und haben separate Konfigurationen. Die gesamte maximale Dauer ist die Summe beider Ebenen.

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:
Zum Beispiel, mit 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:
Aktiviere Debug-Logging, um das Wiederholungsverhalten zu überwachen:

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
Wähle deine Wiederholungsstrategie basierend auf den Anforderungen deiner Anwendung an Zuverlässigkeit vs. Leistung.

Detaillierte Fehlerbehandlung

Ausnahmehierarchie

Das Olostep SDK bietet eine umfassende Ausnahmehierarchie für verschiedene Fehlerszenarien. Alle Ausnahmen erben von Olostep_BaseError. Es gibt drei Hauptfehlerarten, die direkt von Olostep_BaseError erben:
  1. Olostep_APIConnectionError - Netzwerkbezogene Verbindungsfehler
  2. OlostepServerError_BaseError - Fehler, die (irgendwie) vom API-Server ausgelöst werden
  3. OlostepClientError_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:
Dieser Ansatz fängt alle SDK-Fehler ab und liefert klare Informationen darüber, was schiefgelaufen ist. Der Fehlername (z.B. 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 von OlostepServerError_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