API Testing desde una app real: cómo leer el login page request en Chrome DevTools
Antes de automatizar requests en Postman, primero hay que entender qué está pidiendo realmente la aplicación. En este post arranco por el primer paso: leer el GET de la página de login en Chrome DevTools y entender qué datos importan.
La mayoría de tutoriales de API testing arrancan igual: abrir Postman, pegar una URL pública de práctica, mandar un GET y celebrar el status 200.
Eso sirve para aprender sintaxis. Pero no enseña lo más importante: cómo descubrir y leer los requests reales de una aplicación web.
Este post toma otro camino. En vez de empezar desde Postman, empieza desde el navegador. Desde la app. Desde la pantalla de login. Desde lo que la UI realmente le pide al backend.
Ese cambio de punto de partida marca la diferencia.
Porque API testing, al menos en un contexto profesional de QA, no es solo "mandar requests". Es entender:
- Qué endpoint usa la aplicación
- Qué tipo de request dispara
- Qué payload envía
- Qué response recibe
- Qué cookies o tokens necesita para funcionar
- Y dónde conviene validar datos por API en vez de pelearse con la UI
Qué es API Testing en la práctica
La definición más útil es esta:
API testing es validar el contrato y el comportamiento entre cliente y servidor, sin depender de la interfaz visual.
Ese "cliente" puede ser una web, una app mobile, otro backend, o una herramienta como Postman.
Y ese "contrato" incluye: URL, método HTTP (GET, POST, etc.), headers, body o payload, response, status code, y cookies o tokens si la app usa sesión.
En otras palabras: la UI es la cara visible, pero la lógica útil para testing vive unos centímetros más abajo, en los requests que esa UI dispara.
Por qué no empezar directamente con Postman
La razón es simple: sin entender primero qué request hace la app y por qué, Postman se convierte en un editor bonito donde se pegan cosas sin comprender el contexto.
Antes de hablar de colecciones, tests con pm.test o endpoints protegidos, el paso más básico y más útil es leer bien la pestaña Network de Chrome DevTools.
Qué hace la pestaña Network
La pestaña Network muestra todas las comunicaciones entre navegador y servidor.
Cada fila es un intercambio real: una página HTML, un archivo CSS, un script JavaScript, una imagen, un login, una grilla, un filtro, una llamada de datos.
Para API testing, Network es valiosa porque deja ver algo que muchas veces no está documentado de forma visible: qué endpoints está usando realmente la aplicación.
Por qué mirar “Doc” y “Fetch/XHR”
Cuando se abre Network, aparecen muchos tipos de requests. Si se deja todo visible al principio, se vuelve ruido.
El filtro más efectivo para empezar son dos grupos:
Doc
"Doc" viene de document. Suele ser el request principal de una página HTML.
Ejemplo: cuando se abre la pantalla de login, el navegador pide el HTML de esa pantalla.
Esto sirve para entender:
- Cuál es la URL real de la página
- Si la página devuelve cookies iniciales
- Si la app empieza a preparar sesión o tokens desde ese momento
Fetch/XHR
Son requests de datos disparados por JavaScript desde la propia aplicación. Ahí suelen vivir: login, listados, búsquedas, filtros, guardados, endpoints de negocio.
En resumen:
- Doc → carga de la página
- Fetch/XHR → endpoints útiles para testing
Qué mirar al hacer click en una request
Cuando se selecciona una fila en Network, a la derecha aparece el detalle técnico. Las pestañas clave son:
Headers — Muestra metadatos de la request y la response: URL, método, status code, request headers, response headers.
Payload — Muestra qué datos se enviaron al servidor. Si el request es POST, PUT o PATCH, esta pestaña es clave.
Response — Muestra lo que devolvió el servidor: HTML, JSON, texto o error.
Cookies — Muestra cookies de request y response. Especialmente importante cuando hay sesión, autenticación, CSRF o anti-forgery.
Con eso ya se tiene una base sólida para leer requests reales sin adivinar.
Paso 1: leer el GET de la página de login
Para este análisis uso la pantalla de login de la demo de StartSharp / Serenity.
No el login como acción todavía. No el POST. Primero el paso más básico: la carga de la propia página.
En Network, filtrando por Doc, aparece este request:
| Campo | Valor |
|---|---|
| Request URL | https://demo.serenity.is/Account/Login/?ReturnUrl=%2F |
| Request Method | GET |
| Status Code | 200 OK |
Esto ya revela varias cosas importantes.
1. La página de login tiene una URL concreta
Existe una URL específica para esa pantalla: /Account/Login/?ReturnUrl=%2F
No es solo "una pantalla visual". Es una página pedida al servidor con una ruta definida.
2. El método es GET
Tiene sentido: no se están enviando credenciales todavía. Solo se pide la página.
Mentalmente, este request significa: "Servidor, dame el HTML de la pantalla de login."
3. El status es 200
La página cargó correctamente. Todavía no hay autenticación exitosa ni fallida. Solo una carga normal.
Lo importante: los response headers
La parte más interesante aparece en los response headers:
| Response header | Valor |
|---|---|
| Set-Cookie | CSRF-TOKEN=... |
Este dato es una señal fuerte: al cargar la pantalla de login, el servidor ya está entregando una cookie llamada CSRF-TOKEN.
El flujo completo de CSRF viene en posts posteriores. Pero incluso en este paso inicial ya se ve algo clave: la pantalla de login no es un HTML inofensivo. Ya empieza a preparar el contexto de seguridad del flujo.
Qué aparece en Cookies
En la pestaña Cookies del mismo request aparecen:
Request Cookies:
- Una cookie anti-forgery
- Una cookie CSRF-TOKEN
Response Cookies:
- Una nueva CSRF-TOKEN
Conclusión directa: antes de intentar hacer login "a mano" desde Postman, la aplicación ya puso en juego cookies relacionadas con seguridad y sesión.
Esto explica por qué un request puede funcionar copiado desde el navegador y dejar de funcionar después si se rompe ese contexto.
Qué aparece en Payload
En este caso, casi nada complejo. Solo el query string parameter:
ReturnUrl = /
Esto simplemente indica que, después del login, la app quiere redirigir a la raíz /. No es un payload de negocio. No hay usuario ni contraseña acá. Solo la intención de navegación posterior.
Qué devolvió la pestaña Response
La response fue HTML.
Y esto importa porque ayuda a separar dos mundos que al principio se mezclan fácil:
| Request | Devuelve |
|---|---|
GET /Account/Login | HTML de la pantalla |
POST /Account/Login | Procesa credenciales |
| Otros endpoints | Datos JSON |
Hacer esta diferencia es fundamental para no confundir requests de navegación con requests de datos.
Resumen de este paso
Antes de tocar Postman, este primer request ya deja cuatro conclusiones claras:
- La pantalla de login tiene una URL concreta — No es solo una vista del navegador.
- La carga inicial usa GET — Todavía no hay credenciales. Solo carga de página.
- El servidor devuelve HTML — Este request no es una API de datos. Es una página.
- Ya aparecen cookies relevantes — El flujo empieza a preparar contexto de seguridad antes del login propiamente dicho.
Si hay que resumir el Paso 1 en una sola frase:
Antes del login como acción, existe un request previo que carga la página y ya empieza a establecer cookies importantes para el flujo.
Esto justifica empezar desde DevTools y no desde Postman. Primero hay que entender qué está pasando realmente. API testing no es una lista de botones: es lectura de sistema.
Qué sigue
En el próximo post toca analizar el request que sí envía las credenciales:
POST /Account/Login
Ahí aparecen: username, password, método POST, y la parte donde la aplicación deja de mostrar una pantalla y empieza a procesar autenticación real.
Ese es el punto donde el flujo se pone interesante.