A dónde va una petición cuando la envías (y qué pasa en el camino)

Una explicación simple del viaje completo: desde que tu app pide algo hasta que recibe respuesta.

Ya sabes que las aplicaciones se comunican haciendo peticiones.

Tocas un botón. ➡️ La app pide algo. ➡️ Algo responde.

Pero entre ese "pedir" y ese "responder" hay un viaje completo. Y casi nunca se explica.

La mayoría de las veces, cuando aprendes sobre APIs, te dicen:

• "La app hace una petición"
• "El servidor responde"

Y listo.

Como si todo pasara instantáneamente. Como si no hubiera nada en el medio. Pero sí lo hay.

Y entender ese recorrido es lo que te ayuda a dejar de ver las APIs como algo abstracto y empezar a verlas como lo que son: conversaciones con pasos claros. Este artículo es ese mapa.

En el artículo anterior vimos que las aplicaciones no guardan todo localmente.

Cuando necesitan algo, preguntan, hacen una petición y esperan una respuesta.

Eso es una API: el acuerdo que define cómo se hace esa conversación. Pero quedó una pregunta sin responder:

👉 ¿Qué pasa entre el momento en que la app envía la petición y el momento en que recibe la respuesta?

Eso es lo que vamos a ver ahora.

Una petición sale de la app

Imagina que abres una app de Harry Potter y buscas información sobre "Ginny Weasley". (Y sí, si me conoces sabes que soy fan de Harry Potter, así que este ejemplo me hace especialmente feliz 😊)

La app no tiene todos los datos de los personajes guardados en tu teléfono. Así que hace una petición:

GET /personajes?nombre=Ginny+Weasley

Esa petición es un mensaje, no es código que se ejecuta en otro lugar, no es un archivo que se envía, es simplemente información estructurada que dice:

• Qué quiero: información de personajes
• Sobre quién: Ginny Weasley
• Cómo lo pido: usando el método GET

Ese mensaje sale de tu app. Y empieza su viaje.➡️ ✉️

El viaje a través de la red

Tu petición no llega directamente al servidor, pasa por varios puntos en el camino:

1. Sale de tu dispositivo (tu teléfono, tu computadora)
2. Pasa por tu red local (tu WiFi o datos móviles)
3. Viaja por internet (a través de routers, cables, infraestructura)
4. Llega al servidor que tiene la información

Cada uno de esos pasos toma tiempo, a veces milisegundos y a veces segundos; por eso a veces una app carga rápido y otras veces tarda, no siempre es culpa de la app. A veces es el camino.

👉 Prueba este ejemplo interactivo para ver en acción cómo funciona una petición a una API de Harry Potter. Puedes ver el código de la demo en GitHub para entender cómo está construida.

El servidor recibe la petición

Cuando la petición llega al servidor, no se ejecuta automáticamente.

El servidor la recibe y la evalúa.

Piensa en el servidor como un portero que revisa cada mensaje que llega:

• ¿Esta petición está bien formada?
• ¿Tiene permiso para pedir esto?
• ¿Entiendo lo que está pidiendo?

Si algo falla en esta etapa, el servidor responde con un error.

Por ejemplo:

• Si pediste algo que no existe: 404 Not Found
• Si no tienes permiso: 403 Forbidden
• Si la petición está mal hecha: 400 Bad Request

Pero si todo está bien, el servidor pasa a la siguiente etapa.

El proceso de decisión

Aquí es donde pasa la magia. El servidor no solo devuelve información, decide qué devolver.

Siguiendo el ejemplo de la app de Harry Potter:

1. El servidor recibe: GET /personajes?nombre=Ginny+Weasley
2. Busca en su base de datos información sobre "Ginny Weasley"
3. Recopila todos los datos del personaje (casa, varita, patronus, etc.)
4. Puede que incluya información relacionada (amigos, hechizos favoritos)
5. Procesa esa información
6. La estructura en el formato acordado (generalmente JSON)

Todo eso pasa en el backend.

• La app que hizo la petición no sabe cómo funciona ese proceso.
• No sabe si el servidor usa una base de datos SQL o NoSQL.
• No sabe cómo funciona el algoritmo de recomendación.
• No sabe si está en un servidor en California o en Singapur.

Solo sabe que si pide de cierta forma, va a recibir lo que necesita.

Esa es la belleza de las APIs: separan el "qué" del "cómo".

La respuesta regresa

Una vez que el servidor termina de procesar, construye una respuesta:

{
  "id": 8,
  "nombre": "Ginny Weasley",
  "casa": "Gryffindor",
  "poder": 83,
  "hechizo": "Reducto",
  "defensa": 77,
  "imagen": "🧙‍♀️"
}

Esa respuesta hace el viaje de regreso:

1. Sale del servidor
2. Viaja por internet
3. Pasa por tu red local
4. Llega a tu dispositivo
5. Tu app la recibe

El mismo camino, pero en reversa.

Cómo reacciona la app

Cuando la app recibe la respuesta, reacciona, no decide, no procesa lógica compleja, solo toma lo que recibió y lo muestra.

En este caso:

• Muestra la foto del personaje
• Muestra su casa y escudo de Gryffindor
• Muestra información sobre su hechizo
• Muestra información de defensa

Si la respuesta hubiera sido un error, la app mostraría un mensaje de error.

La app depende completamente de lo que el servidor responda.

Por eso cuando una API falla, la app no puede hacer nada, no puede inventar personajes, no puede adivinar información, solo puede mostrar que algo salió mal.

Por qué importa entender este flujo

Porque cuando entiendes que una petición es un viaje, no un evento instantáneo, empiezas a ver por qué:

• Las apps a veces tardan en cargar (el viaje puede ser largo)
• Los errores no siempre son culpa de la app (pueden pasar en cualquier punto del camino)
• El backend tiene que ser confiable (es el que decide qué responder)
• Las APIs bien diseñadas importan (hacen que todo este proceso sea predecible)

No es magia.n Es un proceso con pasos claros.

Y cuando algo falla, saber dónde buscar hace toda la diferencia.

Lo que aprendiste

Una petición no es un solo paso, es un viaje completo:

1. La app envía un mensaje
2. Ese mensaje viaja por la red
3. El servidor lo recibe y evalúa
4. El servidor decide qué responder
5. La respuesta regresa por el mismo camino
6. La app reacciona a lo que recibió

Las aplicaciones dependen de las respuestas.

Los servidores deciden.

Las APIs definen las reglas de esa conversación.

Entender este flujo te da claridad, y esa claridad es lo que te permite construir mejor, debuggear más rápido, y diseñar con más confianza.

Qué sigue

En el siguiente artículo vamos a dar el siguiente paso: construiremos nuestra primera API REST.

Vas a ver cómo crear un servidor que reciba peticiones, procese información y devuelva respuestas.

Ya entiendes el viaje completo de una petición.

Ahora es momento de construir el destino.