Conserva la respuesta que vas a examinar
Empieza con la consulta de la portada: https://api.redditextract.com/v1/search?q=index&subreddit=PostgreSQL&limit=3. Su objetivo es revisar registros disponibles relacionados con index, no describir todas las conversaciones sobre índices de PostgreSQL. Guarda los parámetros y la respuesta que recibas. Si no hay resultados, registra el resultado vacío en vez de crear filas ficticias para completar el ejemplo.
Escribe el recorrido de cada campo
Haz que el mapeo pueda leerse sin ejecutar el código. Para cada columna, indica propiedad observada, tipo aceptado, acción ante la ausencia y si copias o derivas el valor. content_source puede ser una marca local con title o text; source_page puede proceder del registro de consultas. Son nombres de tu salida, no campos adicionales prometidos por la API.
Para cada columna, escribe el origen, los tipos que admites y la acción ante una ausencia. Si tu aplicación requiere un identificador utilizable y no lo encuentra, puede separar ese registro para revisión. No lo sustituyas por una identidad inventada. Conserva el motivo de rechazo junto al registro original para distinguir una limitación de tu modelo de un error de recuperación.
Indica por qué elegiste título o texto
q busca en title y text. Con varios términos, todos deben coincidir dentro de un mismo campo que satisfaga la búsqueda; repartirlos entre ambos campos no basta. Para q=index, inspecciona cada campo y elige el origen del contenido. Si falta text, conserva la ausencia o aplica una sustitución documentada por title con una marca de origen; no la presentes como cuerpo original.
Mantén el texto original junto a una versión normalizada si decides recortar espacios o adaptar saltos de línea. La columna derivada puede facilitar una carga posterior, pero no debe presentarse como la reproducción exacta del valor original. Añade una versión de tus reglas a la salida para comparar cambios del transformador sobre la misma respuesta guardada, sin prometer estabilidad de nuevas consultas.
Comprueba ausencias antes de convertir
Comprueba por separado si un campo existe, si contiene null o si contiene una cadena vacía. Una política local puede convertir algunas de esas situaciones al mismo valor de destino, pero debería conservar un indicador del estado original cuando esa diferencia sea relevante. Así podrás revisar por qué una fila perdió información sin atribuir al archivo una conclusión que no expresa.
No conviertas automáticamente todo a texto. Para score, verifica el tipo y conserva un cero presente en vez de tratarlo como ausencia. Para created_utc, valida la representación antes de derivar una fecha en UTC y guarda el valor recibido. Si hay una conversión fallida, registra el problema localmente; no reemplaces una fecha desconocida por la hora de ejecución.
Explica qué ocurrió con cada registro
Cuenta cuántos registros recibiste, aceptaste y separaste para revisión. Comprueba que esas cifras expliquen el lote procesado y no las anuncies como recuentos del archivo. Si utilizas parent_id o link_id para agrupaciones, conserva las referencias sin resolver: puede faltar el padre y no se garantiza una conversación completa. No intentes pasar esos campos como filtros de búsqueda.
Prueba casos sintéticos identificados como tales: solo título, solo texto, ambos, null explícito y ninguna de las dos propiedades. Comprueba tanto el valor proyectado como su origen. Conserva el objeto original y el motivo de cada rechazo. Si emites como máximo una fila por registro, aceptados y rechazados deben explicar los registros recibidos, sin convertirse en un recuento de todo el archivo.
Decide para qué necesitas otra página
La paginación admite hasta 100 registros por solicitud y 100 páginas por consulta, en orden _doc. Ni esa secuencia ni min_score definen un orden cronológico o por relevancia. Interpreta eq como total exacto, gte como cota inferior y unknown como total no fiable. Una extracción delimitada y documentada resulta más útil que una afirmación de cobertura que la respuesta no demuestra.
Consulta los filtros en la documentación y calcula en precios cuántas recuperaciones vas a ejecutar. Cada éxito cuesta un crédito, aunque tu transformador rechace todas las filas. Reprocesar localmente un archivo guardado no llama a la API; volver a recuperarlo con éxito sí consume otro crédito. Esa distinción permite probar reglas de normalización sin confundir el trabajo local con la contabilidad del servicio.
