HTTP, HTTPS y APIs
Cómo funciona la comunicación web: HTTP estructura las solicitudes, HTTPS las protege y las APIs definen cómo interactúan los sistemas de software.
Qué problema resuelve HTTP
TCP nos da una conexión confiable, pero HTTP define el lenguaje estructurado que permite que clientes y servidores se entiendan entre sí.
- Define cómo los clientes solicitan formalmente recursos específicos (archivos, datos, APIs).
- Estandariza cómo se empaquetan y transmiten los metadatos y el contenido.
- Establece un modelo claro de solicitud–respuesta entre cliente y servidor.
Detalles
Una vez que TCP establece una conexión confiable, las dos máquinas pueden intercambiar bytes de forma segura. Sin embargo, los bytes en bruto no tienen un significado inherente. Sin un protocolo compartido, el servidor no sabría si esos bytes representan una solicitud de archivo, el envío de un formulario o algo completamente distinto.
HTTP (Hypertext Transfer Protocol) define un formato estructurado para la comunicación. Un cliente envía una solicitud (como GET /index.html), y el servidor devuelve una respuesta que contiene información de estado y datos.
HTTP estandariza cómo se solicitan los recursos, cómo se incluye la metadata y cómo se formatean las respuestas. Esto hace que la comunicación web sea predecible e interoperable entre navegadores, servidores y plataformas.
En resumen, TCP garantiza la entrega. HTTP garantiza la comprensión.
Anatomía de una solicitud HTTP
Una solicitud HTTP es un mensaje estructurado compuesto por un método, una ruta de destino, encabezados y un cuerpo opcional.
GET /users/123 HTTP/1.1 Host: api.example.com Authorization: Bearer xyz User-Agent: Browser
POST /users HTTP/1.1 Host: api.example.com Content-Type: application/json Authorization: Bearer xyz { "name": "Alice" }
- Método define la acción prevista (GET, POST, PUT, DELETE).
- Ruta identifica el recurso específico que se solicita.
- Encabezados y cuerpo transportan metadatos y una carga de datos opcional.
Detalles
Una solicitud HTTP comienza con una línea de solicitud. Esto incluye el método y la ruta. Por ejemplo:
GET /users/123 HTTP/1.1
Esto le indica al servidor qué acción se está solicitando y qué recurso es el objetivo.
El método comunica la intención.
GETrecupera datos.POSTenvía datos nuevos.PUTactualiza datos existentes.DELETEelimina datos.
Los encabezados proporcionan contexto adicional, como el tipo de contenido (Content-Type), las credenciales de autenticación (Authorization) o información sobre el cliente (User-Agent).
Por último, algunas solicitudes incluyen un cuerpo. Por ejemplo, una solicitud POST puede incluir datos JSON que se envían al servidor.
Juntos, estos componentes crean una estructura predecible que los servidores pueden analizar e interpretar correctamente.
Estructura de la respuesta HTTP
Una respuesta HTTP devuelve un código de estado, encabezados y un cuerpo — indicando al cliente qué ocurrió y entregando los datos solicitados.
HTTP/1.1 200 OK Content-Type: application/json Content-Length: 27 Cache-Control: no-cache { "id": 123, "name": "Alice" }
HTTP/1.1 404 Not Found Content-Type: application/json Content-Length: 29 Cache-Control: no-cache { "error": "Usuario no encontrado" }
- Código de estado indica el resultado (200, 404, 500).
- Encabezados describen metadatos sobre la respuesta.
- Cuerpo contiene el contenido real devuelto al cliente.
Detalles
Una respuesta HTTP comienza con una línea de estado, como:
HTTP/1.1 200 OK
El código de estado comunica el resultado de la solicitud.
200significa éxito.404significa que no se encontró el recurso.500indica un error del lado del servidor.
Luego vienen los encabezados, que proporcionan metadatos sobre la respuesta. Estos pueden incluir Content-Type (por ejemplo, JSON o HTML), Content-Length, reglas de caché o políticas de seguridad.
Finalmente, el cuerpo contiene los datos solicitados realmente — como una página HTML, un objeto JSON o un archivo.
La estructura de la respuesta garantiza que el cliente entienda tanto qué ocurrió como qué datos se devolvieron.
Por qué HTTP es sin estado
HTTP trata cada solicitud como independiente — el servidor no recuerda automáticamente las interacciones anteriores.
- Cada solicitud se procesa de forma aislada.
- El servidor no conserva memoria de solicitudes anteriores por defecto.
- El estado debe gestionarse explícitamente (por ejemplo, cookies, tokens, sesiones).
Detalles
HTTP está diseñado como un protocolo sin estado. Esto significa que, cuando un cliente envía una solicitud, el servidor la procesa sin asumir ningún contexto previo.
Por ejemplo, si cargas una página web y luego haces clic en un botón, la segunda solicitud no incluye automáticamente la memoria de la primera. Cada solicitud debe contener toda la información necesaria para que el servidor la procese.
La ausencia de estado simplifica la escalabilidad. Como los servidores no dependen de un estado de conexión almacenado, las solicitudes pueden distribuirse entre varias máquinas detrás de un balanceador de carga.
Cuando las aplicaciones necesitan continuidad — como sesiones de inicio de sesión o carritos de compra — implementan el estado explícitamente usando cookies, identificadores de sesión o tokens de autenticación.
Qué añade HTTPS
HTTPS protege HTTP mediante la capa TLS sobre TCP, protegiendo los datos en tránsito.
- HTTPS cifra todo el tráfico HTTP entre el cliente y el servidor.
- HTTPS verifica la identidad del servidor mediante certificados digitales.
- HTTPS evita la manipulación mediante comprobaciones criptográficas de integridad.
Detalles
HTTPS significa HTTP sobre TLS (Transport Layer Security). En lugar de enviar mensajes HTTP en texto plano, los datos se cifran antes de la transmisión.
Con HTTPS, todo lo que está dentro de la solicitud y la respuesta HTTP — incluidos los encabezados y el cuerpo — se cifra. Esto evita que atacantes en la red puedan leer información sensible como contraseñas o tokens.
HTTPS también requiere que el servidor presente un certificado digital válido. El navegador verifica este certificado frente a Autoridades de Certificación de confianza para confirmar la autenticidad del servidor.
Además, TLS aplica comprobaciones criptográficas de integridad para garantizar que los datos no hayan sido modificados durante el tránsito.
En resumen, HTTPS protege la confidencialidad, la autenticidad y la integridad de la comunicación web.
El handshake de TLS
Antes de que comience la comunicación cifrada, TLS realiza un handshake para acordar algoritmos, verificar la identidad y establecer claves de cifrado compartidas.
Cliente
Servidor
Cliente: Aquí están los métodos de cifrado que admito.
- Client Hello propone algoritmos de cifrado compatibles y datos aleatorios.
- Server Hello + Certificate selecciona parámetros y demuestra la identidad.
- Key Agreement establece un secreto compartido para el cifrado.
Detalles
Cuando un cliente se conecta a un servidor HTTPS, TLS primero realiza un handshake antes de enviar cualquier dato HTTP.
El proceso comienza con un Client Hello. El cliente propone algoritmos criptográficos compatibles (cipher suites) y envía datos aleatorios que se usarán más adelante en la generación de claves.
El servidor responde con un Server Hello, seleccionando los parámetros de cifrado. También envía su certificado digital, que contiene su clave pública y está firmado por una Certificate Authority de confianza.
El cliente verifica el certificado y realiza un proceso de key agreement (como Diffie-Hellman). Ambas partes derivan de forma independiente el mismo secreto compartido sin transmitirlo directamente.
Una vez que el handshake se completa, se establecen claves de cifrado simétricas y todo el tráfico HTTP posterior se cifra.
Certificados y confianza
Los certificados digitales permiten a los clientes verificar que se están comunicando con el servidor legítimo, no con un atacante.
- Una Autoridad de Certificación (CA) firma y valida las identidades de los servidores.
- Los certificados contienen la clave pública del servidor.
- Los navegadores verifican la propiedad del dominio antes de establecer confianza.
Detalles
Un certificado digital es emitido por un tercero de confianza llamado Autoridad de Certificación (CA). La CA verifica que la organización que solicita el certificado realmente controla el nombre de dominio.
El certificado contiene la clave pública del servidor, junto con información de identificación sobre el dominio. Esta clave pública se usa durante el handshake de TLS para establecer una comunicación cifrada.
Cuando tu navegador se conecta a un sitio web, comprueba si el certificado está firmado por una CA en la que ya confía. Los navegadores incluyen una lista integrada de Autoridades de Certificación de confianza.
Si el certificado es válido, no ha expirado y coincide con el dominio solicitado, el navegador continúa con la conexión segura. Si no, muestra una advertencia.
Por lo tanto, la confianza en HTTPS se basa en una cadena:
Tú confías en la CA → La CA confía en el servidor → Tú confías en el servidor.
¿Qué es una API?
Una API define el contrato estructurado que permite que los sistemas de software se comuniquen de forma predecible.
- Define el conjunto de operaciones que un sistema expone a clientes externos.
- Establece un contrato estricto para la estructura de las solicitudes, la autenticación y el formato de respuesta.
- Crea un límite estable que desacopla la implementación interna de los consumidores externos.
Detalles
Una API (Application Programming Interface) es una especificación formal de cómo interactúan los componentes de software. Define qué operaciones están disponibles y cómo se accede a ellas.
En los sistemas web, las APIs normalmente usan HTTP. Los clientes envían solicitudes a endpoints específicos (como /users/123) usando métodos definidos como GET o POST.
La API también define el formato de solicitud esperado (por ejemplo, JSON en el cuerpo de la solicitud) y la estructura del formato de respuesta devuelto por el servidor.
Sin APIs, los sistemas dependerían de convenciones no documentadas o de integraciones fuertemente acopladas. Las APIs crean límites claros, lo que permite el desarrollo independiente, la escalabilidad y la interoperabilidad entre servicios.
APIs REST
REST es un estilo arquitectónico que usa métodos HTTP y URLs basadas en recursos para crear APIs web predecibles y escalables.
GET /users/42
{
"id": 42,
"name": "Alex",
"role": "admin"
}- Organiza las APIs alrededor de recursos y sus representaciones, no de acciones al estilo RPC.
- Usa la semántica estándar de HTTP para expresar la intención (GET = lectura segura, POST = crear, etc.).
- Impone interacciones sin estado para permitir escalabilidad horizontal.
Detalles
REST (Representational State Transfer) organiza las APIs alrededor de recursos, no de acciones. Un recurso se representa mediante una URL como /users o /orders/123.
En lugar de incrustar verbos en la URL, REST usa métodos HTTP para definir la operación:
GETrecupera datos.POSTcrea nuevos datos.PUTactualiza datos existentes.DELETEelimina datos.
Las APIs REST son sin estado, lo que significa que cada solicitud contiene toda la información necesaria. El servidor no depende de solicitudes anteriores para procesar la actual.
La mayoría de las APIs REST intercambian datos en formato JSON, que es ligero, legible para humanos y fácil de analizar por máquinas.
Esta estructura hace que las APIs REST sean consistentes, escalables y fáciles de entender en sistemas distribuidos.
Escenarios comunes de fallo en HTTP/HTTPS/API
No todos los fallos web ocurren en la misma capa: los errores pueden originarse en la lógica de la aplicación, el transporte o la seguridad TLS.
- 404 No encontrado → La capa de aplicación no pudo encontrar el recurso.
- 500 Error interno del servidor → El servidor encontró un error interno durante el procesamiento.
- Conexión rechazada o error de certificado SSL → Fallo en la capa de transporte o TLS.
Detalles
Un error 404 No encontrado significa que el servidor es accesible, pero la ruta o el recurso solicitado no existe. Normalmente se trata de un problema de enrutamiento a nivel de aplicación.
Un 500 Error interno del servidor indica que la solicitud llegó al servidor, pero algo falló durante la ejecución, como un crash, una excepción no controlada o un fallo de base de datos.
Un error Conexión rechazada ocurre antes en la pila. El cliente no puede establecer una conexión TCP, a menudo porque el servidor está caído o no hay ningún proceso escuchando en el puerto de destino.
Un error de certificado SSL ocurre durante el handshake de TLS si el certificado no es válido, ha expirado o no coincide con el dominio. El navegador bloquea la conexión para proteger al usuario.
Una advertencia de contenido mixto aparece cuando una página HTTPS intenta cargar recursos HTTP. Esto rompe las garantías de seguridad de HTTPS y los navegadores modernos lo señalan.
Entender dónde ocurre un fallo — en la aplicación, el transporte o TLS — es fundamental para depurar de forma eficaz.
Sección de preguntas
1 / 5