Cómo funciona HTTP
Escribes una dirección en la barra, pulsas Intro y, un momento después, la página aparece en pantalla. Mientras tanto, donde no se ve, hay una breve conversación. El navegador pide: "¿Me das esta página?", y el servidor se la entrega: "Aquí la tienes". El acuerdo que hay detrás de este pedir y entregar es lo que mueve la web: HTTP.
¿Me lo das? Aquí lo tienes
Antes vimos que, gracias a TCP, los datos llegan completos y en orden. Entonces, ¿de qué hablan el navegador y el servidor con esos datos?
La conversación en la web es muy sencilla. El navegador le pide al servidor: "¿Me das esta página?", y el servidor se la entrega: "Aquí la tienes". El pedido se llama petición y la entrega, respuesta. HTTP es el acuerdo que fija qué forma tienen las peticiones y las respuestas.
Toca el navegador para enviar una petición al servidor. Cuando el servidor devuelve una respuesta, el par queda completo.
Una petición, una respuesta. La web funciona con esta pareja sencilla. Quien habla primero es siempre el navegador, y el servidor solo responde a las peticiones que recibe. El servidor nunca toma la palabra por su cuenta.
Por eso, al servidor le basta con recibir por turno las peticiones de innumerables navegadores y responderlas una a una. Pero no todas las peticiones dicen "¿me das esto?". Cada petición indica la acción que quiere hacer, y eso es lo que veremos a continuación.
La acción de una petición
Toda petición lleva una acción que dice qué quiere hacer. La más común es GET, que significa "dame esto, por favor" y trae algo de vuelta. Cada vez que abres una página, la petición que envía tu navegador es un GET.
En el lado contrario está POST, que significa "toma esto, por favor" y envía algo al servidor, como cuando publicas un comentario o envías tu usuario y contraseña para iniciar sesión. Traer es GET; enviar es POST.
Toca una acción para elegirla. GET trae y POST envía. Una flecha muestra hacia dónde viajan los datos en cada acción.
Con solo GET y POST se explica casi todo lo que hacemos en la web: GET para abrir una página y leerla, POST para escribir algo y enviarlo.
La respuesta también lleva una marca breve. Es un número de tres cifras llamado código de estado: 200 si todo salió bien, 404 si esa página no existe. Un solo número dice si la petición tuvo éxito o falló. Por ahora basta con recordar estos dos.
Como a un cliente nuevo, cada vez
HTTP tiene un rasgo curioso. En cuanto atiende una petición, olvida por completo quién acaba de pedir qué. Aunque la misma persona venga dos veces, la trata cada vez como a un cliente que ve por primera vez.
No tiene recuerdos del tipo "¿no estuvo usted aquí hace un momento?". Esta forma de no recordar las peticiones anteriores se llama no tener estado; en inglés, stateless.
Envía dos peticiones como la misma persona. La segunda vez, el servidor te saluda igual que a un desconocido. HTTP no recuerda las peticiones anteriores.
Que te saluden como a un desconocido en la segunda visita parece un poco frustrante. Pero se hizo así a propósito. Como el servidor no tiene que recordar a cada cliente, su trabajo es ligero y puede atender a la vez una enorme cantidad de peticiones.
A cambio, para que el servidor reconozca a "la persona de antes", cada petición tiene que llevar una marca. Esa marca es la cookie, que veremos un poco más adelante, en la lección sobre sesiones y cookies.
Juntar piezas en una página
Una página web no llega entera con una sola petición. Primero el navegador trae con GET el documento con el texto y el esqueleto. Al leerlo, descubre que también hacen falta un archivo de imagen y un archivo que define el estilo.
Entonces envía más peticiones: dame la imagen, dame el estilo. Solo después de intercambiar peticiones y respuestas varias veces y juntar las piezas una a una, la página queda completa.
Toca cada pieza para pedirla. El texto, la imagen y el estilo llegan como respuestas, y la página se va llenando paso a paso.
Con todas las piezas reunidas, los huecos se llenaron. A nuestros ojos parece aparecer de golpe, pero en realidad es el resultado de muchas peticiones y respuestas: un esqueleto, una imagen y un archivo de estilo, cada uno pedido y traído por separado.
Una página grande puede necesitar decenas de peticiones así, a veces más de cien. Como internet es rápido, todo termina en un abrir y cerrar de ojos, y solo sentimos que la página apareció.
En resumen
En pocas palabras: la web funciona con pares de petición y respuesta, y cada petición lleva una acción como GET (traer) o POST (enviar). Cada respuesta trae un número que indica si tuvo éxito o falló.
Una página se arma juntando piezas a lo largo de muchas peticiones y respuestas. Y como HTTP no recuerda las peticiones anteriores, trata cada petición como a un cliente nuevo. Gracias a esta sencillez, el servidor atiende muchas peticiones con poco esfuerzo. Ese es el acuerdo llamado HTTP.
Toca en orden los puntos clave para repasar. (petición y respuesta → acciones GET y POST → terriblemente olvidadizo → juntar piezas en una página)
Ahora ya sabes cómo van y vienen las páginas web. El navegador pide y el servidor responde: esa es la base de la web.
Pero los navegadores que usan las personas no son los únicos que hablan HTTP. Los programas también intercambian datos por HTTP, como cuando una app del tiempo trae del servidor el pronóstico de hoy. La próxima lección trata de la API, la ventanilla donde un programa le pide un trabajo a otro. Cómo se recuerdan el carrito o la sesión iniciada viene después, en la lección sobre sesiones y cookies.