HTTP y HTTPS: el protocolo de la web y sus códigos de estado
Guía completa sobre cómo funciona la comunicación cliente-servidor, qué aporta TLS en HTTPS y qué significa cada familia de códigos HTTP — del 200 al 500.
Cada vez que abres una app, un dashboard o una API, por debajo casi siempre hay una conversación HTTP. Entender ese protocolo — y sus códigos de respuesta — te permite depurar más rápido, diseñar APIs más claras y explicar incidentes sin adivinar.
¿Qué es HTTP?
HTTP (HyperText Transfer Protocol) es un protocolo de capa de aplicación que define cómo un cliente (navegador, app móvil, otro servidor) solicita recursos a un servidor y cómo este responde. Es stateless por naturaleza: cada petición es independiente, aunque cookies, sesiones o tokens JWT permiten simular continuidad.
- Texto legible en su forma base (método, ruta, cabeceras, cuerpo).
- Modelo petición → respuesta: siempre inicia el cliente.
- Extensible mediante cabeceras personalizadas y distintos tipos de contenido.
GET /api/users/42 HTTP/1.1
Host: api.ejemplo.com
Accept: application/json
Authorization: Bearer eyJhbGciOi...
HTTP/1.1 200 OK
Content-Type: application/json
{"id":42,"name":"Ana"}
¿Qué es HTTPS y por qué importa?
HTTPS es HTTP envuelto en TLS (Transport Layer Security). Cifra la comunicación, autentica el servidor mediante certificados y protege la integridad de los datos en tránsito. Sin HTTPS, contraseñas, tokens y datos personales pueden ser interceptados en redes no confiables.
- Confidencialidad: terceros no leen el tráfico fácilmente.
- Integridad: detecta manipulación del mensaje en camino.
- Autenticación del servidor: el certificado valida quién responde.
Anatomía de una petición y una respuesta
Una petición incluye método (GET, POST, PUT, PATCH, DELETE…), URL, versión del protocolo, cabeceras y, opcionalmente, cuerpo. La respuesta trae versión, código de estado numérico, frase descriptiva, cabeceras y cuerpo (HTML, JSON, archivo, etc.).
Métodos más usados
- GET — leer un recurso sin efectos secundarios esperados.
- POST — crear un recurso o ejecutar una acción.
- PUT / PATCH — reemplazar o actualizar parcialmente.
- DELETE — eliminar un recurso.
- OPTIONS — descubrir qué métodos permite el servidor (útil con CORS).
Los códigos de estado: el lenguaje del servidor
El código de estado es un número de tres dígitos. El primero indica la familia: 1xx informativo, 2xx éxito, 3xx redirección, 4xx error del cliente, 5xx error del servidor. La frase (ej. "Not Found") es humana; lo que importa en integraciones es el número.
2xx — Éxito
La petición se completó correctamente. Respuesta estándar para GET exitoso.
Recurso creado, habitual tras POST. Suele incluir Location con la nueva URL.
Éxito sin cuerpo en la respuesta. Común en DELETE o actualizaciones sin payload de vuelta.
3xx — Redirección
El recurso cambió de URL de forma permanente. Los buscadores actualizan el índice.
Redirección temporal. El cliente puede seguir usando la URL original después.
El recurso en caché sigue vigente; ahorra ancho de banda en assets estáticos.
4xx — Error del cliente
Sintaxis inválida o datos mal formados. Revisa el body y las cabeceras.
Falta autenticación o el token no es válido / expiró.
Autenticado pero sin permiso para ese recurso o acción.
Ruta o recurso inexistente. También se usa para ocultar recursos privados.
Conflicto con el estado actual (ej. email duplicado, versión obsoleta).
JSON válido pero reglas de negocio no cumplidas (validación semántica).
Rate limit superado. Respeta Retry-After si viene en cabeceras.
5xx — Error del servidor
Fallo no controlado en el servidor. Revisar logs y trazas.
Proxy o gateway recibió respuesta inválida del upstream.
Servidor sobrecargado o en mantenimiento. Puede ser temporal.
El upstream no respondió a tiempo. Común en microservicios lentos.
Buenas prácticas al diseñar APIs
- Usa el código que describe la situación real: no devuelvas 200 con un JSON de error.
- Sé consistente: mismas reglas para autenticación, validación y paginación.
- Documenta qué códigos puede devolver cada endpoint.
- En producción, combina códigos HTTP con mensajes claros y un identificador de error interno.
Dominar HTTP y HTTPS no es memorizar números: es entender quién falló (cliente, red, servidor) y qué hacer después. En NotFoundGroup aplicamos estos criterios en cada API y producto web que entregamos.