Tecnología · GUÍA PRÁCTICA
¿requests falla con JSONDecodeError en char 0? Prueba los bytes antes de analizar
Conserva URL final, estado, Content-Type, longitud de bytes y un prefijo seguro; separa respuesta vacía, HTML/texto, stream consumido y JSON.
“Expecting value: line 1 column 1 (char 0)” solo indica que el analizador no encontró un valor JSON al inicio; no demuestra comillas malas ni una biblioteca rota.
Antes de reintentar, fija solicitud, redirecciones, estado, tipo, longitud y prefijo redactado de una sola respuesta.
Congela un intercambio fallido antes de reintentar
Registra método, destino saneado, status_code, URL final y redirecciones de la misma llamada; conserva hora y correlation ID si existen.
No registres credenciales, cookies, Authorization ni un body ilimitado; usa headers seleccionados y un prefijo breve redactado.
Mide bytes antes de elegir parser
Lee response.content una vez en una variable limitada y registra su longitud. Cero bytes significa que no existe documento JSON.
Con stream=True demuestra quién consume; iter_content, raw.read o middleware pudieron avanzar hasta EOF.
Interpreta estado, redirecciones y Content-Type juntos
Requests documenta que 204 o un body inválido hace fallar json(). Un 204 puede ser correcto: aplica el contrato del endpoint.
Examina URL final y redirects. Login, rate limit, 404 HTML o 502 gateway suelen empezar por “<” y fallar en char 0.
Separa fallo HTTP de fallo de representación
Decide si raise_for_status va antes de analizar según el contrato; algunas APIs devuelven errores JSON y otras HTML.
Si el estado es inesperado repara auth, endpoint, redirect, proxy o upstream; si falla la representación conserva una muestra segura.
Analiza una vez y demuestra la salida
Solo llama response.json() o json.loads(body) cuando el contrato permite JSON y hay bytes no vacíos.
Repite con mismo runtime y red: estado esperado, tipo compatible, bytes no nulos, un parse correcto y schema válido cierran el incidente.
