Skip to content

Qué es HTTP y cómo funciona ​

1. ¿Qué es HTTP? ​

HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación que permite intercambiar información entre clientes y servidores.

Un protocolo establece reglas que indican cómo deben comunicarse dos sistemas: qué información pueden enviar, cómo se estructura y cómo se interpreta.

HTTP es uno de los fundamentos de la Web. Se utiliza para solicitar páginas, descargar imágenes, enviar formularios, consultar APIs y transmitir información entre aplicaciones.

Por ejemplo, cuando escribes una dirección en el navegador y presionas Enter, el navegador puede utilizar HTTP para solicitar los recursos necesarios para mostrar la página.

2. ¿Cómo funciona HTTP? ​

HTTP utiliza un modelo de comunicación conocido como cliente-servidor.

  • Cliente: realiza una solicitud. Puede ser un navegador, una aplicación móvil u otro programa.
  • Servidor: recibe la solicitud, la procesa y normalmente devuelve una respuesta.

El proceso básico es el siguiente:

text
Cliente
   |
   | Solicitud HTTP (request)
   v
Servidor
   |
   | Procesa la solicitud
   | y realiza la operación necesaria
   v
Respuesta HTTP (response)
   |
   v
Cliente recibe la respuesta
y actúa según el resultado

Imagina que entras a una tienda en línea y abres la página de un producto:

  1. El navegador solicita la página.
  2. El servidor recibe la petición y devuelve el contenido correspondiente.
  3. El navegador interpreta el HTML, aplica los estilos y ejecuta el JavaScript necesario.
  4. Si la página necesita información adicional, puede realizar más solicitudes, por ejemplo, para consultar los productos disponibles.

Importante: una página web normalmente requiere varias solicitudes HTTP, no solamente una. El documento HTML puede referenciar hojas de estilo, scripts, imágenes y otros recursos que el navegador necesita cargar.

3. ¿Qué contiene una solicitud HTTP? ​

Una solicitud HTTP puede incluir varios componentes:

  • Método: indica qué tipo de operación se desea realizar.
  • URL: identifica el recurso al que se quiere acceder.
  • Encabezados (headers): proporcionan información adicional sobre la solicitud.
  • Cuerpo (body): contiene datos que se envían al servidor, cuando corresponde.

Por ejemplo, una solicitud para consultar los datos de un producto podría representarse así:

http
GET /api/productos/15 HTTP/1.1
Host: tienda.example.com
Accept: application/json

Esto significa que el cliente solicita el recurso /api/productos/15 y prefiere recibir una respuesta en formato JSON.

Este ejemplo es una representación simplificada de una solicitud HTTP/1.1.

Los métodos HTTP más comunes ​

MétodoUso habitualEjemplo
GETConsultar información.Obtener los datos de un producto.
POSTEnviar información o solicitar la creación de un recurso.Registrar un cliente.
PUTCrear o reemplazar la representación de un recurso, según la API.Reemplazar los datos de un producto.
PATCHModificar parcialmente un recurso.Cambiar el precio de un producto.
DELETESolicitar la eliminación de un recurso.Eliminar un producto.

Estos métodos describen la intención de la solicitud, pero el servidor debe tener configurada la operación correspondiente.

Por ejemplo, enviar un DELETE no garantiza que un registro se elimine: el servidor podría rechazar la solicitud por falta de permisos o porque el recurso no existe.

4. ¿Qué contiene una respuesta HTTP? ​

Cuando el servidor procesa una solicitud, normalmente devuelve una respuesta con:

  • Código de estado: indica el resultado de la solicitud.
  • Encabezados: proporcionan información sobre la respuesta.
  • Cuerpo: contiene los datos devueltos, si corresponde.

Ejemplo:

http
HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 15,
  "nombre": "Llanta deportiva",
  "precio": 25000
}

En este caso:

  • 200 OK indica que la solicitud se procesó correctamente.
  • Content-Type: application/json indica que el cuerpo contiene JSON.
  • El cuerpo incluye la información del producto.

La respuesta no tiene que contener siempre datos. Por ejemplo, un 204 No Content indica que la solicitud se procesó correctamente y no devuelve contenido en el cuerpo.

5. ¿Qué son los códigos de estado HTTP? ​

Los códigos de estado permiten conocer el resultado de una solicitud.

RangoSignificadoEjemplos
1xxRespuestas informativas.100 Continue
2xxSolicitud procesada correctamente.200 OK, 201 Created
3xxRedirecciones u otras acciones relacionadas.301 Moved Permanently, 304 Not Modified
4xxProblemas con la solicitud o el acceso.400 Bad Request, 401 Unauthorized, 404 Not Found
5xxErrores al procesar la solicitud en el servidor.500 Internal Server Error, 503 Service Unavailable

Por ejemplo, si el navegador solicita una página que no existe, el servidor puede responder con 404 Not Found.

Si se produce un fallo inesperado en el servidor, puede devolver 500 Internal Server Error.

Puedes consultar los detalles en la nota [[Errores HTTP comunes y cómo solucionarlos]].

6. ¿Qué son los headers o encabezados? ​

Los encabezados son campos que transmiten metadatos sobre una solicitud o respuesta HTTP.

Algunos de los más importantes son:

EncabezadoPropósito
Content-TypeIndica el tipo de contenido del cuerpo del mensaje.
AcceptIndica los tipos de respuesta que el cliente acepta.
AuthorizationTransporta credenciales o información de autenticación, según el mecanismo utilizado.
Cache-ControlDefine directivas relacionadas con el almacenamiento en caché.
CookieEnvía cookies almacenadas para el contexto correspondiente.
Set-CookiePermite al servidor indicar que el cliente debe almacenar una cookie.
LocationPuede indicar la ubicación de un recurso, por ejemplo, en una redirección.

Los encabezados ayudan a los sistemas a interpretar el contenido, gestionar la autenticación, controlar la caché y aplicar distintas reglas de comunicación.

7. ¿Qué es el cuerpo de una solicitud o respuesta? ​

El cuerpo (body) contiene los datos que se transmiten, cuando el mensaje los necesita.

Por ejemplo, al registrar un cliente, una aplicación podría enviar:

json
{
  "nombre": "Ana",
  "correo": "ana@example.com"
}

El servidor recibe los datos, los valida y determina qué operación debe realizar.

En una respuesta, el cuerpo podría contener los datos de un cliente, un documento HTML, una imagen u otro tipo de contenido.

El formato depende de la operación y de lo que admitan los sistemas involucrados.

8. ¿Qué diferencia hay entre HTTP y HTTPS? ​

HTTPS es HTTP protegido mediante TLS (Transport Layer Security).

TLS proporciona, entre otras propiedades, cifrado de la comunicación, integridad de los datos y autenticación del servidor mediante certificados correctamente validados.

HTTPHTTPS
No protege por sí mismo el contenido mediante cifrado de transporte.Protege la comunicación mediante TLS.
Los datos pueden quedar expuestos si se intercepta el tráfico sin otra protección.Dificulta que terceros lean o modifiquen el tráfico durante el transporte.
No utiliza TLS como parte de la conexión HTTP.Requiere establecer una conexión TLS correctamente configurada.

HTTPS es fundamental cuando se transmiten contraseñas, datos personales, información de pago o cualquier contenido que requiera protección.

Sin embargo, HTTPS no garantiza que una página sea legítima ni que la aplicación sea segura. Protege la comunicación con el servidor autenticado, pero no corrige automáticamente las vulnerabilidades de la aplicación.

9. ¿HTTP necesita una conexión TCP? ​

Depende de la versión de HTTP.

  • HTTP/1.1: normalmente utiliza TCP.
  • HTTP/2: también utiliza TCP, con mejoras para multiplexar solicitudes dentro de una conexión.
  • HTTP/3: utiliza QUIC, que funciona sobre UDP y proporciona mecanismos de transporte seguros.

No necesitas memorizar todos los detalles del transporte para empezar a desarrollar aplicaciones web. Lo importante es entender que HTTP define cómo se estructuran e interpretan las solicitudes y respuestas, mientras que otros protocolos se encargan de transportar esa información.

10. ¿Cómo se relaciona HTTP con el frontend, el backend y las APIs? ​

HTTP es uno de los mecanismos más comunes para comunicar las distintas partes de una aplicación web.

Por ejemplo, en una tienda en línea:

  1. El frontend muestra un formulario para registrar un producto.
  2. El usuario completa los datos y pulsa Guardar.
  3. El frontend envía una solicitud HTTP al backend.
  4. El backend valida los datos y realiza las operaciones necesarias.
  5. El backend devuelve una respuesta HTTP.
  6. El frontend interpreta la respuesta y muestra un mensaje al usuario.

La solicitud podría enviar datos como estos:

json
{
  "nombre": "Llanta deportiva",
  "precio": 25000
}

Y el servidor podría responder con un estado 201 Created si el producto se creó correctamente.

Una API HTTP define cómo un cliente puede interactuar con un servicio mediante rutas, métodos, datos y respuestas.

HTTP no es lo mismo que una API: HTTP es el protocolo de comunicación, mientras que una API define las operaciones disponibles y las reglas para utilizarlas.

11. Cómo inspeccionar HTTP en el navegador ​

Los navegadores incluyen herramientas para observar las solicitudes y respuestas de una página.

Para utilizarlas:

  1. Abre una página web.
  2. Abre las herramientas de desarrollador con F12.
  3. Selecciona la pestaña Network o Red.
  4. Recarga la página.
  5. Selecciona una solicitud de la lista.

Normalmente podrás revisar:

  • La URL solicitada.
  • El método HTTP.
  • El código de estado.
  • Los encabezados enviados y recibidos.
  • Los datos del cuerpo, cuando estén disponibles.
  • El tiempo que tardó la solicitud.

Esta herramienta resulta especialmente útil para investigar errores HTTP, problemas de APIs, recursos que no cargan y solicitudes que tardan demasiado.

Conclusión ​

HTTP es un protocolo fundamental de la Web porque permite que los clientes y servidores intercambien solicitudes y respuestas siguiendo reglas comunes.

Comprender sus métodos, encabezados, cuerpos y códigos de estado facilita el desarrollo y la depuración de aplicaciones web, independientemente del lenguaje o framework utilizado.

La idea principal es recordar que HTTP define cómo se comunican los sistemas, pero no determina por sí solo toda la lógica de la aplicación.