La grilla no vive en la UI: cómo leer el endpoint Customer/List en Chrome DevTools
La grilla de clientes no vive en la UI: los datos vienen de un endpoint separado. Análisis del request Customer/List, su payload con filtros y columnas, y la response JSON con TotalCount.
En el post anterior, el foco estuvo en el login real: el POST /Account/Login, el payload con credenciales y la cookie AspNetAuth que aparece después de autenticarse.
Ese paso servía para algo más que entender el login. Servía para preparar el terreno para lo que viene después.
Porque una vez autenticado, la pregunta ya no es "cómo entra el usuario al sistema", sino esta:
¿De dónde salen realmente los datos de la grilla de clientes?
Y ahí aparece algo importante.
Al entrar al módulo de clientes, no aparece un solo request. Aparecen dos.
Dos requests distintos al abrir la pantalla de clientes
En Network, filtrando por Doc y Fetch/XHR, se ve claramente esta secuencia:
GET /Northwind/CustomerPOST /Services/Northwind/Customer/List
A simple vista, la pantalla de clientes parece una sola cosa. En realidad no lo es.
Técnicamente, está separada en dos capas distintas: una request que carga la página HTML del módulo, y otra request que trae los datos de la grilla.
Esa diferencia es fundamental para API testing.
Primer request: la página del módulo
La primera request relevante es:
| Campo | Valor |
|---|---|
| Request URL | https://demo.serenity.is/Northwind/Customer |
| Request Method | GET |
| Response | HTML |
Qué significa
Este request cumple un rol parecido al del login page request del paso 1. No trae los datos de negocio. Trae la pantalla del módulo Clientes.
Por eso el método es GET, la response es HTML, siguen viajando cookies de sesión, y la UI del módulo se monta a partir de ahí.
Mentalmente, este request dice: "Servidor, dame la página del módulo de clientes."
Eso explica por qué en la response vuelve a aparecer HTML y no JSON.
Segundo request: la data real de la grilla
Después de cargar la página del módulo, aparece la request importante:
| Campo | Valor |
|---|---|
| Request URL | https://demo.serenity.is/Services/Northwind/Customer/List |
| Request Method | POST |
| Response | JSON |
Ese es el request que realmente alimenta la grilla.
No carga una vista. No trae HTML. Trae los datos concretos que después la UI dibuja en la tabla.
Y eso cambia por completo el enfoque del testing. Si ese endpoint ya devuelve la lista real de clientes, entonces la grilla visual deja de ser el único lugar donde validar datos.
Qué muestra el payload
En la pestaña Payload del request List aparece esto:
{
"Take": 100,
"EqualityFilter": {
"Country": "",
"City": "",
"Representatives": []
},
"IncludeColumns": [
"CustomerID",
"CompanyName",
"ContactName",
"ContactTitle",
"Region",
"PostalCode",
"Country",
"City"
]
}
Ese payload vale mucho más de lo que parece.
Take: 100 — Le dice al backend cuántos registros traer. En este caso, la grilla pide hasta 100 registros.
EqualityFilter — Acá viajan filtros exactos. En esta captura están vacíos (Country: "", City: "", Representatives: []), lo que significa que la grilla pide los datos sin filtros activos.
IncludeColumns — Define qué columnas necesita la UI. No está trayendo "todo porque sí". Está pidiendo explícitamente campos como CustomerID, CompanyName, ContactName, ContactTitle, Region, PostalCode, Country y City.
Este detalle es especialmente revelador: la UI no solo consume datos, también le dice al backend qué forma de datos necesita.
Qué devuelve la response
En la pestaña Preview y Response aparece lo más importante del endpoint:
{
"Entities": [...],
"Skip": 0,
"Take": 100,
"TotalCount": 91
}
Varias señales fuertes acá:
Entities — La lista de clientes. Cada objeto trae campos como CustomerID, CompanyName, ContactName, ContactTitle, Address, City, PostalCode, Country, Phone, Fax y Representatives.
Skip: 0 — No se está salteando ningún registro. Empieza desde el primero.
Take: 100 — Coincide con lo pedido en el payload.
TotalCount: 91 — Este dato es clave. El backend reconoce 91 registros totales para esa consulta. Y eso ya permite pensar la validación de otra manera.
Por qué TotalCount: 91 importa tanto
Validar esta grilla solo desde UI implica enfrentarse a problemas típicos: scroll, renderizado parcial, sincronización visual, virtualización, paginación, localización exacta de filas y columnas.
Desde este endpoint, en cambio, ya se tiene: la cantidad total de registros, la estructura de cada entidad, los campos exactos que devuelve el backend, y los datos en formato JSON — mucho más fácil de recorrer y validar.
Para volumen y contenido, la API ofrece una base mucho más estable que la tabla visual.
No significa que la UI deje de importar. Significa que cada capa puede validar mejor cosas distintas.
Las cookies siguen viajando
En la pestaña Cookies del request List siguen apareciendo cookies relevantes: AspNetAuth, cookie anti-forgery y CSRF-TOKEN.
Esto confirma algo que se venía insinuando desde los pasos anteriores: el endpoint de la grilla no vive aislado. Sigue dependiendo del contexto autenticado.
Eso explica por qué copiar el request desde el navegador puede funcionar una vez y después dejar de hacerlo si se rompe la sesión o cambian las cookies.
El flujo completo hasta acá
| Paso | Request | Acción | Resultado |
|---|---|---|---|
| 1 | GET /Account/Login/?ReturnUrl=%2F |
Carga pantalla de login | Devuelve CSRF-TOKEN |
| 2 | POST /Account/Login |
Envía Username y Password | Devuelve AspNetAuth |
| 3 | GET /Northwind/Customer |
Carga página del módulo Clientes | HTML del módulo |
| 4 | POST /Services/Northwind/Customer/List |
Pide datos de la grilla | JSON con Entities y TotalCount |
La UI que se ve en pantalla no es un bloque único. Es una secuencia de requests con responsabilidades distintas.
UI vs API: división inteligente del testing
La tentación natural al validar una grilla grande es ir directo a Selenium: encontrar filas, leer celdas, scrollear, comparar contenido visual.
Pero con este análisis queda claro que hay una división más efectiva:
La UI sirve para validar: que la pantalla cargue, que la grilla renderice, que filtros y ordenamiento funcionen visualmente, que el usuario pueda interactuar.
La API sirve para validar: cantidad total de registros, estructura de datos, contenido exacto, respuesta del backend ante filtros.
No es una pelea entre UI y API. Es una división más inteligente del trabajo de validación.
Resumen del paso 3
- La pantalla de clientes no hace una sola request — Hace al menos dos: una para cargar la página y otra para traer la data.
- El request importante para la grilla es Customer/List — Ese es el endpoint de negocio que devuelve JSON.
- El payload explica la lógica de la grilla — Take, filtros y columnas son parte de cómo la UI le pide datos al backend.
- La response da todo lo necesario para validar más que la UI — Especialmente con Entities y TotalCount.
- La autenticación sigue importando — El endpoint protegido sigue viajando con cookies de sesión y contexto de seguridad.
Cierre de esta mini-saga
Con estos tres pasos
Cesar Beas Suarez
Cesar Beas Suarez
Cesar Beas Suarez
queda claro cómo mirar una app web real desde abajo: primero la pantalla de login, después el POST de autenticación, después el endpoint protegido que alimenta la grilla.
Este recorrido es mucho más útil que arrancar directamente con una URL pública en Postman, porque obliga a entender no solo qué request existe, sino en qué momento aparece, qué depende de qué y qué contexto necesita para funcionar.
Qué sigue
El siguiente paso natural ya no es solo leer requests en DevTools. Es empezar a reproducir este flujo fuera del navegador: cargar contexto, autenticarse, pegarle a Customer/List y validar la response con tests reales en Postman.
Ahí es donde esta serie deja de ser solo análisis de requests y se convierte en API testing ejecutable.