Peticiones HTTP reales en el navegador

Inspeccionar peticiones HTTP en el navegador es la forma más directa de entender cómo viaja la información entre tu aplicación y un API. Con las dev tools de Chrome o Firefox puedes ver URLs, status codes, headers y tiempos de respuesta en tiempo real, algo esencial si estás aprendiendo a consumir APIs.

Usando el Fake Store API de Platzi como ejemplo, vas a entender cómo se ve una petición real, cómo cambia según el tipo de contenido que pides y cómo manipular los headers desde el navegador.

Cómo abrir el inspector de red en el navegador

El primer paso es hacer clic derecho sobre la página y seleccionar Inspeccionar. Dentro del panel, ve a la pestaña Network y recarga el sitio. Ahí aparece el primer request: el que estructura la página HTML completa, junto con todos los requests subsecuentes que el navegador dispara para traer imágenes, estilos y scripts.

Al seleccionar la petición principal verás la URL (https://fakeapi.platzi.com), el verbo HTTP usado (en este caso GET) y el status code. Si aparece 304, significa que el recurso no ha cambiado desde tu última visita, así que el navegador usa la versión en caché [01:05].

¿Qué significa el status code 304? Indica que el recurso no fue modificado desde la última visita. El navegador entonces usa la copia en caché en lugar de descargarlo de nuevo.

Qué información revelan los headers de una petición

Los headers son metadatos que viajan con cada petición y respuesta. En el panel encontrarás dos bloques: los request headers que envía tu navegador y los response headers que devuelve el servidor.

En los response headers aparecen valores como:

• cache-control: indica cuánto tiempo puede el navegador guardar el recurso en caché.
• date: la fecha exacta en que se procesó la solicitud.
• server: identifica al servidor que respondió.
• Headers personalizados con prefijo X-: convención para campos no estándar [01:45].

Del lado del request, el header Accept le dice al servidor qué formato esperas recibir. Si pides una página, será text/html. Si pides una imagen, el navegador envía algo como image/webp, image/apng, image/svg+xml.

Cómo cambia el status code según el recurso

Si pegas la URL de una imagen del sitio en una pestaña nueva e inspeccionas la petición, verás un status code 200, porque es la primera vez que la solicitas. El Content-Type devuelto será image/jpeg y el Content-Length mostrará el peso real del archivo en bytes [02:50]. El navegador interpreta esos bytes como imagen gracias justamente al Content-Type.

Cómo editar y reenviar peticiones desde Firefox

Firefox tiene una funcionalidad muy útil para desarrollo: Edit and Resend. Te permite modificar los headers de una petición y volver a enviarla sin salir del navegador.

Por ejemplo, si abres un endpoint del API y haces clic derecho sobre el request, puedes cambiar el header Accept a application/json. Al reenviar, el servidor responderá con Content-Type: application/json y Firefox mapea automáticamente la respuesta como JSON estructurado [04:20].

Esto demuestra cómo el protocolo HTTP funciona como una conversación: tú declaras qué esperas recibir y el servidor responde en ese formato si lo soporta.

¿Para qué sirve Edit and Resend en Firefox? Sirve para modificar headers de una petición existente y reenviarla, ideal para probar cómo responde un API ante diferentes formatos sin escribir código.

Qué pasa cuando una URL no existe

Si cambias el endpoint a algo que no existe, por ejemplo añadiendo /platzi, el servidor devolverá un status code 404. Firefox incluso enlaza directamente a la documentación de Mozilla, donde puedes consultar qué significa cada código de estado en una fuente oficial y confiable [05:30].

Cómo medir tiempos de respuesta y filtrar tráfico

Las dev tools también muestran cuánto tardó cada petición. En el ejemplo, el navegador esperó 76 milisegundos por la solicitud y 128 milisegundos por la respuesta completa. Esos números son clave para detectar cuellos de botella.

El panel permite filtrar el tráfico por tipo de recurso:

• HTML: las páginas principales del sitio.
• CSS: las hojas de estilo que dan formato visual.
• JS: los scripts de JavaScript que se ejecutan.
• XHR: peticiones asíncronas que hace la página al servidor para traer datos.
• Fonts: las fuentes tipográficas.
• Media: cualquier archivo multimedia distinto a imágenes.
• WebSockets: protocolo de comunicación en tiempo real.

Cómo simular conexiones lentas o sin red

Dos opciones muy útiles dentro del panel son Disable cache y Throttling. La primera evita que el navegador use versiones cacheadas, así siempre ves un status code 200 fresco en lugar de 304. La segunda simula condiciones de red distintas: puedes ponerte en modo offline para ver cómo reacciona tu aplicación sin conexión, o bajar el ancho de banda para probar cómo se comporta en redes lentas [07:40].

Esta capacidad de simular escenarios reales convierte a las dev tools en un instrumento básico para cualquier persona que trabaje con APIs. Tanto Chrome como Firefox cumplen el mismo propósito (revisar y hacer debugging de las peticiones), pero cada uno tiene matices propios.

¿Cuál es tu navegador favorito para inspeccionar peticiones HTTP y qué dev tools te han funcionado mejor? Cuéntame en los comentarios.