Ciclo de vida de una petición de API · Mapas mentales
Ciclo de vida de una petición de API. Un mapa mental editable con ramas de colores, ideas secundarias y conexiones. Las líneas curvas muestran relaciones; las flechas aparecen cuando importa la dirección.
Una petición de API no es un solo salto: es una cadena (resolución DNS, establecimiento de la conexión, cifrado, enrutamiento, procesamiento y respuesta) y cada etapa pertenece a una capa distinta.
Ciclo de vida de una petición de API · Mapas mentales
El lienzo interactivo de MindMap de esta explicación: cada carril, cada fila y cada flecha de arriba forma parte de un diagrama real de QueryChart que puedes abrir y editar.
Cómo leer este mapa mental
- Empieza por el tema central y sigue una rama de color para explorar sus ideas.
- Las líneas curvas muestran relaciones; las flechas aparecen cuando importa la dirección.
Find the service
Esta rama reúne “The first round trip is DNS — the domain is resolved to an IP address before a single request is sent. See How DNS Works for the full lookup chain.”, “A TCP connection is established”, “The encryption handshake negotiates keys before the HTTP request travels — see How HTTPS Works for what happens inside it.”.
Send request
Esta rama reúne “The HTTP request is sent”, “With several servers behind one address, the load balancer picks a healthy instance for each request and spreads traffic across them.”.
Application
Esta rama reúne “Handler validates and processes the request”, “Server queries the database”.
Return response
Esta rama reúne “Server serialises the response”, “Response travels back through the same path”, “Client parses and renders the response”.
Conexiones entre ramas
DNS, TCP y TLS preceden a la petición HTTP: tres idas y vueltas antes de que se ejecute nada de código de aplicación.
El balanceador de carga hace que muchos servidores parezcan una sola dirección; el cliente nunca ve el servidor real.
La consulta a la base de datos es el salto más lento de la mayoría de las llamadas a una API, y por eso importan la caché y los índices.
La respuesta rehace el camino de la petición: las dos direcciones cruzan la misma red y el mismo balanceador de carga.
El ciclo de vida compone los demás diagramas: DNS, HTTPS y REST son etapas de este mismo viaje.
Relaciones clave y conclusiones
- DNS, TCP y TLS preceden a la petición HTTP: tres idas y vueltas antes de que se ejecute nada de código de aplicación.
- El balanceador de carga hace que muchos servidores parezcan una sola dirección; el cliente nunca ve el servidor real.
- La consulta a la base de datos es el salto más lento de la mayoría de las llamadas a una API, y por eso importan la caché y los índices.
- La respuesta rehace el camino de la petición: las dos direcciones cruzan la misma red y el mismo balanceador de carga.
- El ciclo de vida compone los demás diagramas: DNS, HTTPS y REST son etapas de este mismo viaje.
Cuándo usar este diagrama
- Enseñar a un ingeniero nuevo por qué la latencia de una API es más que el código del servidor: las etapas de red y de establecimiento son reales.
- Depurar la lentitud: el lienzo nombra los saltos que hay que medir: tiempo de DNS, TTFB, tiempo de servidor y tiempo de transferencia.
- Anclar una conversación sobre balanceo de carga y caché en el punto del viaje donde encaja cada uno.
Cómo funciona
Adapta el tema central
Cambia el nombre del tema para adaptarlo a tu proyecto o clase.
Desarrolla las ramas
Edita las ideas y añade ejemplos o notas.
Conecta ideas relacionadas
Dibuja conexiones entre ramas; usa flechas cuando la dirección importe.
Preguntas frecuentes
¿Cuáles son las etapas de una petición de API?
Antes de enviar nada por HTTP, el cliente resuelve el dominio por DNS, abre una conexión TCP y hace un handshake TLS. Después la petición viaja hasta un balanceador de carga, que la enruta a un servidor de aplicación; el servidor la valida y la procesa, consulta la base de datos y serializa una respuesta; y la respuesta vuelve por el mismo camino. Las tres columnas del diagrama son exactamente esos tres grupos de etapas.
¿Por qué es lenta una llamada a una API antes de que el servidor haga nada?
Porque la resolución DNS, la conexión TCP y el handshake TLS son idas y vueltas reales que ocurren antes de enviar un solo byte de HTTP. En una conexión en frío pueden tardar más que el propio procesamiento de la petición. Por eso el diagrama empieza con la columna «Antes de la petición»: la mayor parte de la latencia de una primera petición es el establecimiento, no el código del servidor.
¿Cuál es el papel del balanceador de carga en el ciclo de vida de la petición?
El balanceador de carga es la puerta de entrada estable detrás de la cual viven los servidores reales. Acepta la petición, elige una instancia sana y reenvía el tráfico, y también suele ser donde terminan las comprobaciones de salud y el TLS. Los clientes nunca saben qué servidor los atendió, y eso es lo que permite añadir y quitar servidores sin cambiar el cliente.
¿Por qué vuelve la respuesta por el mismo camino?
Porque la conexión es el camino: la respuesta viaja por la misma conexión TCP/TLS, por la misma red y por el mismo balanceador de carga que llevaron la petición. La simetría importa en la operación (un salto lento o roto afecta a las dos direcciones), y por eso el diagrama dibuja la columna de la respuesta como el reflejo de la de la petición, en lugar de dar por gratis el viaje de vuelta.
Editar este mapa mental en QueryChart
Abre este mapa mental en un lienzo editable. Mueve ideas, añade ramas y dibuja conexiones.