Paquete PyPI: olostep | Requisitos: Python 3.11+
Instalación
Autenticación
Obtén tu clave API desde el Panel de Olostep.Inicio Rápido
El SDK ofrece dos opciones de cliente dependiendo de tu caso de uso:Cliente Sincrónico (`Olostep`)
Mejor para: Scripts y casos de uso simples donde prefieres operaciones bloqueantes.
El cliente sincrónico proporciona una interfaz más sencilla y bloqueante, ideal para comenzar si eres nuevo en async/await.
El cliente sincrónico proporciona una interfaz más sencilla y bloqueante, ideal para comenzar si eres nuevo en async/await.
Cliente Asincrónico (`AsyncOlostep`)
Mejor para: Aplicaciones en producción y manejo de muchas solicitudes concurrentes.
El cliente asincrónico proporciona operaciones no bloqueantes y es la opción recomendada para aplicaciones en producción que necesitan alto rendimiento.
El cliente asincrónico proporciona operaciones no bloqueantes y es la opción recomendada para aplicaciones en producción que necesitan alto rendimiento.
Cliente Sincrónico (Olostep)
El cliente sincrónico (Olostep) proporciona una interfaz bloqueante perfecta para scripts y casos de uso simples.
Raspado Web Básico
Procesamiento por Lotes
Rastreo Web Inteligente
Mapeo de Sitios
Respuestas Potenciadas por IA
Cliente Asincrónico (AsyncOlostep)
El cliente asincrónico (AsyncOlostep) es el cliente recomendado para aplicaciones de alto rendimiento, servicios backend y cuando necesitas manejar muchas solicitudes concurrentes.
Raspado Web Básico
Procesamiento por Lotes
Rastreo Web Inteligente
Mapeo de Sitios
Respuestas Potenciadas por IA
Referencia del SDK
Estructura de Métodos
Ambos clientes del SDK proporcionan la misma interfaz limpia y pythónica organizada en espacios de nombres lógicos:| Espacio de Nombres | Propósito | Métodos Clave |
|---|---|---|
scrapes | Extracción de URL única | create(), get() |
batches | Procesamiento multi-URL | create(), info(), items() |
crawls | Recorrido de sitios web | create(), info(), pages() |
maps | Extracción de enlaces | create(), urls() |
answers | Extracción con IA | create(), get() |
retrieve | Recuperación de contenido | get() |
Manejo de Errores
Captura todos los errores del SDK usando la clase de excepción base:Reintentos Automáticos
El SDK reintenta automáticamente en errores transitorios (problemas de red, problemas temporales del servidor) basado en la configuración deRetryStrategy. Puedes personalizar el comportamiento de reintento pasando una instancia de RetryStrategy al crear el cliente:
Características Avanzadas
Coerción Inteligente de Entradas
El SDK maneja inteligentemente varios formatos de entrada para máxima conveniencia:Opciones Avanzadas de Raspado
Procesamiento por Lotes con IDs Personalizados
Rastreo Inteligente
Mapeo de Sitios con Filtros
Recuperación de Respuestas
Recuperación de Contenido
Registro
Habilita el registro para depurar problemas:INFO (recomendado), DEBUG (detallado), WARNING, ERROR
Configuración de Estrategia de Reintentos
La claseRetryStrategy controla cómo el SDK de Olostep maneja errores transitorios de la API a través de reintentos automáticos con retroceso exponencial y jitter. Esto ayuda a asegurar una operación confiable en entornos de producción donde problemas de red temporales, límites de tasa y sobrecarga del servidor pueden causar fallos intermitentes.
Comportamiento Predeterminado
Por defecto, el SDK utiliza la siguiente configuración de reintentos:- Reintentos máximos: 5 intentos
- Retraso inicial: 2 segundos
- Retroceso: Exponencial (2^intento)
- Jitter: 10-90% del retraso (aleatorizado)
- Intento 1: Inmediato
- Intento 2: ~2-3.6s de retraso
- Intento 3: ~4-7.2s de retraso
- Intento 4: ~8-14.4s de retraso
- Intento 5: ~16-28.8s de retraso
Configuración Personalizada
Cuándo Ocurren los Reintentos
El SDK reintenta automáticamente en:- Problemas temporales del servidor (
OlostepServerError_TemporaryIssue) - Respuestas de tiempo de espera (
OlostepServerError_NoResultInResponse)
Reintentos de Transporte vs Llamador
El SDK tiene dos capas de reintentos:- Capa de transporte: Maneja fallos de conexión a nivel de red (DNS, tiempos de espera, etc.)
- Capa de llamador: Maneja errores transitorios a nivel de API (controlado por
RetryStrategy)
Calculando la Duración Máxima
Ejemplos de Configuración
Aquí hay algunos ejemplos de cómo configurar la estrategia de reintentos para diferentes casos de uso.Estrategia Conservadora
Estrategia Agresiva
Sin Reintentos (Fallo Rápido)
Estrategia de Alto Rendimiento
Entendiendo el Jitter
El jitter añade aleatorización para prevenir problemas de “manada tronante” cuando muchos clientes reintentan simultáneamente. El jitter se calcula como:initial_delay=2.0, jitter_min=0.1, jitter_max=0.9:
- Intento 0: base=2.0s, jitter=0.2-1.8s, final=2.2-3.8s
- Intento 1: base=4.0s, jitter=0.4-3.6s, final=4.4-7.6s
- Intento 2: base=8.0s, jitter=0.8-7.2s, final=8.8-15.2s
Mejores Prácticas
Para Aplicaciones en Producción
Para Desarrollo/Pruebas
Para Operaciones por Lotes
Monitoreo y Depuración
El SDK registra información de reintentos en el nivel DEBUG:Manejo de Errores
Cuando se agotan todos los reintentos, se lanza el error original:Consideraciones de Rendimiento
- Memoria: Cada intento de reintento usa memoria adicional para objetos de solicitud/respuesta
- Tiempo: El tiempo total de operación puede ser significativamente más largo con reintentos habilitados
- Límites de API: Los reintentos cuentan contra tus límites de uso de la API
- Red: Más tráfico de red debido a los intentos de reintento
Manejo de Errores Detallado
Jerarquía de Excepciones
El SDK de Olostep proporciona una jerarquía de excepciones comprensiva para diferentes escenarios de fallo. Todas las excepciones heredan deOlostep_BaseError.
Hay tres tipos principales de errores que heredan directamente de Olostep_BaseError:
Olostep_APIConnectionError- Fallos de conexión a nivel de redOlostepServerError_BaseError- Errores levantados (de alguna manera) por el servidor de la APIOlostepClientError_BaseError- Errores levantados por el SDK del cliente
Por Qué los Errores de Conexión Son Separados
Olostep_APIConnectionError es separado de los errores del servidor porque representa fallos a nivel de red que ocurren antes de que la API pueda procesar la solicitud. Estos son problemas de capa de transporte (fallos de DNS o HTTP, tiempos de espera, conexión rechazada, etc.) en lugar de errores a nivel de API. Los códigos de estado HTTP (4xx, 5xx) se consideran respuestas de API y se categorizan como errores del servidor, incluso si indican problemas.
Manejo de Errores Recomendado
Para la mayoría de los casos de uso, captura el error base e imprime el nombre del error:OlostepServerError_AuthFailed) es lo suficientemente descriptivo para entender el problema.
Manejo de Errores Granular
Si necesitas un manejo de errores más específico, captura los tipos de error específicos directamente. Evita usarOlostepServerError_BaseError o OlostepClientError_BaseError - estas clases base solo indican quién levantó el error (servidor vs cliente), no quién es responsable de solucionarlo. Este es un detalle de implementación que no ayuda con la lógica de manejo de errores.
En su lugar, captura tipos de error específicos que indiquen el problema real:
Configuración
Variables de Entorno
| Variable | Descripción | Predeterminado |
|---|---|---|
OLOSTEP_API_KEY | Tu clave API | Requerido |
OLOSTEP_BASE_API_URL | URL base de la API | https://api.olostep.com/v1 |
OLOSTEP_API_TIMEOUT | Tiempo de espera de solicitud (segundos) | 150 |