HTTP: la conversación entre el cliente y el servidor¶

Antes de escribir una sola línea de HTML conviene entender qué ocurre exactamente cuando escribimos una dirección en el navegador y presionamos Enter. Todo lo que construiremos durante el semestre —una página con Thymeleaf, un servicio REST, una aplicación Angular— se apoya en el mismo mecanismo: un cliente pide algo, un servidor responde.

Ese mecanismo tiene nombre: HTTP.

📎 Material de apoyo del módulo: HTML-CSS-JS-DesarrolloWeb.pptx

¿Qué es HTTP?¶

HTTP (HyperText Transfer Protocol) es el protocolo que define cómo un cliente solicita recursos a un servidor y cómo este responde. El cliente suele ser un navegador, pero también puede ser una herramienta como Postman, un comando de terminal como curl o, más adelante en el curso, una aplicación Angular consumiendo nuestra propia API.

Cliente y servidor comunicándose mediante el protocolo HTTP

El esquema es deliberadamente simple: de un lado está el cliente WWW, que no almacena la información pero sabe pedirla y mostrarla; del otro el servidor WWW, que custodia los recursos —páginas, imágenes, datos— y los entrega cuando alguien los solicita correctamente. Entre ambos, HTTP funciona como el idioma común que hace posible el intercambio.

HTTP es un protocolo sin estado (stateless)

Cada petición es independiente de las anteriores: el servidor no recuerda nada de lo que ocurrió antes. Si pedimos una página y luego otra, para el servidor son dos conversaciones sin relación entre sí.

Esa amnesia deliberada es lo que permite que un servidor atienda a millones de usuarios sin guardar el estado de cada conversación, y es la razón por la que existen mecanismos adicionales —cookies, sesiones y tokens— para manejar autenticación. Los veremos en detalle en el módulo de seguridad.

La URL: la dirección del recurso¶

Para pedir algo hay que saber cómo nombrarlo. Esa es la función de la URL (Uniform Resource Locator): identificar de manera única un recurso dentro de la web.

Una URL no es una cadena arbitraria; tiene partes con significado propio:

Partes de una URL: protocolo, servidor, ruta y parámetros

Parte	Ejemplo	Qué indica
Protocolo	`http://` · `https://`	Cómo se va a hablar con el servidor. `https` añade cifrado sobre el canal.
Servidor	`www.santafecampeon.com`	A qué máquina se le pide. El nombre de dominio se traduce a una dirección IP.
Ruta	`/todoscontratodos/cuadrangulares/final`	Qué recurso específico se solicita dentro de ese servidor.
Parámetros	`?estrella=9&figura=perez`	Información adicional para afinar la petición. Van después de `?` y se separan con `&`.

Los parámetros merecen una nota. Se escriben como pares clave=valor y sirven para filtrar, ordenar o paginar resultados sin necesidad de crear una ruta distinta para cada combinación posible. Cuando en el proyecto construyamos listados paginados, la página solicitada y el tamaño de página viajarán exactamente así.

Una URL bien diseñada se lee sola

La ruta debería describir qué recurso se pide, no qué acción se ejecuta. /procesos/15 se entiende sin explicación; /verProcesoPorId.php?accion=mostrar obliga a adivinar. Esta idea será central cuando diseñemos la API REST del proyecto.

Tres formas de hacer la misma petición¶

Una petición HTTP no es propiedad del navegador. Es un mensaje de texto que cualquier programa puede enviar, y verlo desde distintos ángulos ayuda a desmitificarlo.

Desde el navegador¶

La forma cotidiana: se escribe la dirección y el navegador arma la petición, la envía, recibe la respuesta y la dibuja en pantalla.

https://independientesantafe.com/

Todo el trabajo ocurre oculto. Es cómodo, pero no deja ver el mecanismo.

Desde Postman¶

Postman permite construir la petición pieza por pieza: escoger el método, escribir la URL, añadir encabezados, definir el cuerpo y observar la respuesta cruda con su código de estado. Es la herramienta que usaremos para probar los servicios REST del backend antes de que exista un frontend que los consuma.

Desde la consola¶

La forma más reveladora. Con telnet se abre una conexión directa al puerto del servidor y se escribe el mensaje HTTP a mano:

ubuntu@marshando-controllers:~$ telnet info.cern.ch 80
Trying 188.184.100.182...
Connected to webafs703.cern.ch.
Escape character is '^]'.

GET /hypertext/WWW/TheProject.html HTTP/1.1 host: info.cern.ch

HTTP/1.1 400 Bad Request
Date: Tue, 25 Jul 2023 01:26:35 GMT
Server: Apache
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
Connection closed by foreign host.

Vale la pena detenerse en este ejemplo por dos razones.

La primera es qué servidor se está consultando: info.cern.ch aloja la primera página web de la historia, publicada por Tim Berners-Lee. Casi treinta años después sigue respondiendo peticiones.

La segunda es que la petición falló, y eso lo vuelve más instructivo. El servidor respondió 400 Bad Request, es decir: "tu mensaje no está bien formado y no puedo entenderlo". El error está en haber escrito el encabezado host: en la misma línea que la petición, cuando el protocolo exige que vaya en una línea aparte. HTTP es un protocolo de texto, sí, pero con reglas estrictas de formato: un salto de línea mal puesto es suficiente para que la conversación se rompa.

Independientemente del medio, el principio no cambia: el cliente envía un mensaje HTTP y el servidor responde con otro.

El ciclo completo: de la petición a la página¶

Cuando abrimos una página real, no ocurre una petición sino muchas, encadenadas.

Diagrama de secuencia: peticiones HTTP sucesivas y renderizado del HTML

El flujo es el siguiente:

Primera petición. El cliente solicita el documento principal y el servidor responde con el HTML.
El cliente lee el HTML y descubre que ese documento hace referencia a otros recursos: hojas de estilo, scripts, imágenes, fuentes.
Peticiones adicionales. Por cada recurso referenciado, el cliente lanza una nueva petición HTTP: una para el CSS, otra para cada imagen, otra para cada archivo JavaScript.
Renderizado (HTML Rendering). Con todas las piezas en la mano, el navegador construye la página y la dibuja en pantalla.

Hay aquí una consecuencia práctica que conviene fijar desde ahora: el HTML llega primero y solo. El navegador no recibe "una página": recibe un documento que le indica qué más debe ir a buscar. Por eso una página con muchos recursos externos tarda más en aparecer completa, y por eso el orden en que se declaran los estilos y los scripts dentro del HTML afecta lo que el usuario ve mientras la página termina de cargar.

Anatomía de una petición HTTP¶

Toda petición está compuesta por cuatro elementos:

Elemento	Descripción
Método	La acción que se quiere realizar: `GET`, `POST`, `PUT`, `DELETE`, entre otros.
URL del recurso	Qué recurso se solicita.
*Encabezados (headers)*	Información adicional sobre la petición: formato aceptado, tipo de contenido enviado, credenciales de autenticación.
*Cuerpo (body)*	Opcional. Los datos que se envían al servidor. Se usa principalmente en `POST` y `PUT`.

Métodos HTTP¶

El método expresa la intención de la petición. Esta es la parte que más adelante estructurará por completo el diseño de nuestra API REST:

Método	Intención	Ejemplo en el proyecto
`GET`	Consultar un recurso, sin modificar nada.	Obtener la lista de procesos de una empresa.
`POST`	Crear un recurso nuevo.	Registrar un proceso.
`PUT`	Actualizar un recurso existente.	Modificar los datos de un proceso.
`DELETE`	Eliminar un recurso.	Borrar un proceso.

GET no debe modificar información

Un GET es una consulta y debe poder repetirse las veces que sea sin efectos secundarios. Si una petición cambia datos en el servidor, el método correcto es POST, PUT o DELETE. Respetar esta convención no es formalismo: navegadores, buscadores y sistemas de caché asumen que un GET es seguro y pueden repetirlo por su cuenta.

Encabezados¶

Los encabezados son pares clave: valor que acompañan al mensaje y describen el contexto de la petición. Algunos que veremos con frecuencia:

Content-Type — en qué formato va el cuerpo del mensaje (por ejemplo, application/json).
Accept — en qué formato espera el cliente la respuesta.
Authorization — las credenciales o el token de quien hace la petición.
Host — a qué servidor se dirige la petición, necesario cuando una misma máquina aloja varios sitios.

La respuesta HTTP¶

El servidor responde con tres elementos: un código de estado, sus propios encabezados y un cuerpo con el recurso solicitado o con un mensaje de error.

El código de estado es lo primero que se debe mirar, porque resume en tres dígitos qué ocurrió. Se agrupan en familias según el primer dígito:

Familia	Significado	Códigos frecuentes
2xx	Éxito. La petición se procesó correctamente.	`200 OK`, `201 Created`, `204 No Content`
3xx	Redirección. El recurso está en otra parte.	`301 Moved Permanently`, `302 Found`
4xx	Error del cliente. La petición está mal formulada o no está permitida.	`400 Bad Request`, `401 Unauthorized`, `403 Forbidden`, `404 Not Found`
5xx	Error del servidor. La petición era válida, pero algo falló al procesarla.	`500 Internal Server Error`, `503 Service Unavailable`

La distinción entre 4xx y 5xx es la más útil en la práctica y conviene interiorizarla desde ya: un 4xx señala que quien pidió se equivocó; un 5xx, que quien respondió falló. Cuando el frontend reciba un 400, el problema estará en los datos que envió; cuando reciba un 500, habrá que revisar el backend.

En el ejemplo de la consola vimos un 400 Bad Request en acción: el servidor del CERN estaba perfectamente sano; el mensaje mal formado era nuestro.

Responder con el código correcto es parte del diseño

Cuando construyamos los controladores REST del proyecto, devolver 201 al crear un recurso, 404 cuando no existe y 400 cuando los datos son inválidos no es un detalle cosmético: es la forma en que el backend le comunica al frontend qué ocurrió sin que este tenga que interpretar textos. Es un criterio evaluado en la segunda entrega.

Lo que sigue¶

Con el protocolo claro, el resto del módulo se ocupa de qué viaja dentro de esas respuestas:

HTML — el contenido y su estructura.
CSS — la presentación visual.
JavaScript — el comportamiento y la interactividad.