Fetch API: cómo validar respuestas con response.ok

Contenido del curso

Event Loop and Execution Model

Callbacks

Promesas

Async/Await Javascript Moderno

Casos reales de uso de asincronismo

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:006:24

Fetch API: cómo validar respuestas con response.ok

Curso de Asincronismo con Javascript

Clase 15 de 18

Clase 15 / 18

Recursos

Tu código en el navegador opera dentro de una burbuja de seguridad que le impide acceder a archivos del disco duro o comunicarse con otros servidores. La API Fetch es la herramienta que rompe ese aislamiento y conecta tu aplicación con datos reales: usuarios, clima, cotizaciones financieras y mucho más. Sin embargo, Fetch opera bajo las reglas de la asincronía y las promesas, y si no comprendes su ciclo de vida, tu aplicación podría mostrar datos vacíos o romperse silenciosamente.

¿Cómo funciona una promesa en Fetch?

Cuando ejecutas fetch(url), el navegador no detiene la ejecución para esperar la respuesta. En su lugar, te entrega inmediatamente un objeto promesa en estado pending [0:40]. Imagina que pides comida a domicilio: el restaurante te da un recibo con un número de orden. Ese recibo es la promesa. Puedes seguir haciendo otras cosas mientras la cocina trabaja en segundo plano.

Eventualmente, esa promesa cambiará de estado:

Fulfilled: la respuesta llegó correctamente.
Rejected: ocurrió un fallo catastrófico de red, como pérdida de conexión o servidor caído.

Tu trabajo como desarrollador es escribir código que reaccione ante cualquiera de estos dos desenlaces.

¿Por qué un error 404 no rechaza la promesa?

Aquí existe una trampa técnica que confunde a muchos [1:26]. Fetch solo marca la promesa como rejected ante fallos de red. Si el servidor responde con un error 404, para Fetch eso es un éxito: la comunicación funcionó, el servidor simplemente respondió "no tengo eso".

Por esta razón, no puedes confiar ciegamente en que una promesa cumplida trae datos útiles. Es obligatorio verificar manualmente la propiedad response.ok. Si es false, debes lanzar un error tú mismo para detener el proceso.

¿Por qué response.json() devuelve otra promesa?

El cuerpo de la respuesta no llega como un objeto JavaScript listo para usar. Llega como un flujo de datos (stream) que debe ser leído y procesado [2:10]. Cuando llamas a response.json(), obtienes otra promesa. Esto crea una cadena de dos pasos inevitables:

Primero, esperas a que la red entregue la cabecera y el estado.
Segundo, esperas a que el navegador termine de leer y decodificar el cuerpo del mensaje.

Si intentas acceder a los datos sin esperar esta segunda promesa, obtendrás un error. Es físicamente imposible leer un libro que todavía se está imprimiendo.

¿Qué relación tienen async/await con los generadores?

Manejar cadenas de promesas con múltiples .then() puede volverse difícil de leer. La sintaxis async/await es, en esencia, una evolución de los generadores [2:50]. Cuando usas await, le dices a la función: "pausa tu ejecución en esta línea exacta, guarda tu estado en memoria y no avances hasta que la promesa se resuelva". Es la misma mecánica de yield, pero automatizada para promesas.

Un punto vital: cuando await pausa la función, se refiere solo a esa función específica [3:18]. No congela el navegador ni bloquea el hilo principal. Gracias al event loop, el navegador sigue libre para procesar clics, animaciones y otras tareas. Es una pausa no bloqueante: tu función se va a la pila de espera y el motor de JavaScript continúa trabajando. Cuando los datos llegan, el motor despierta tu función exactamente donde se quedó.

¿Cómo construir una función Fetch robusta paso a paso?

Veamos la implementación práctica con manejo correcto de errores [3:50]:

javascript async function obtenerUsuario() { try { const respuesta = await fetch(url); // Primera pausa if (!respuesta.ok) { throw new Error('Error en la petición'); } const datos = await respuesta.json(); // Segunda pausa console.log(datos); } catch (error) { console.error(error); } }

Los elementos clave de esta estructura son:

El bloque try envuelve toda la lógica para capturar errores de forma centralizada.
La verificación de respuesta.ok lanza manualmente el error si el servidor devuelve un 404 o cualquier código de fallo.
El bloque catch atrapa tanto errores de red como errores de parsing en un solo lugar.

Sin esa verificación manual de response.ok, un 404 no saltará automáticamente al bloque catch. Este es el detalle más importante para escribir peticiones Fetch confiables.

Dominar estos patrones te prepara para conectar tu aplicación con APIs más exigentes, donde la gestión de la latencia y los tiempos de espera será aún más crítica. ¿Qué API te gustaría consumir primero con Fetch? Comparte tu experiencia en los comentarios.

Event Loop and Execution Model

Quien domina el Asincronismo domina JS

Microtasks vs Macrotasks

Callbacks

Higher-Order Functions y el patrón Callback

Convenciones Error-First y Node.js

Callback Hell: La Pirámide del Destino

Promesas

El ciclo de vida de una Promesa

Consumiendo y encadenando Promesas

Manejo de errores y rechazos

Combinadores de Promesas

Async/Await Javascript Moderno

La función async y la palabra clave await

Manejo de errores con try/catch en funciones async

Patrones de ejecución: secuencial vs paralelo

Refactorizando Promise chains a async/await

Casos reales de uso de asincronismo

Presentacion Proyecto

Fetch API: cómo validar respuestas con response.ok

Archivos del proyecto

Integrar LLMs con Async y Abort Controller

integracion con LLMs

Fetch API: cómo validar respuestas con response.ok

Progreso del curso

Event Loop and Execution Model

Callbacks

Promesas

Async/Await Javascript Moderno

Casos reales de uso de asincronismo

Recursos

Recursos