Semántica HTTP Explicada: Domine RFC 9110 para el Desarrollo Web Moderno
En 2022, el IETF publicó el RFC 9110, un documento monumental que dejó obsoletos varios RFC antiguos (como el RFC 7231) para convertirse en la autoridad definitiva sobre la Semántica HTTP. Mientras que HTTP/2 y HTTP/3 cambiaron la forma en que los datos se transportan, la semántica —el significado de los métodos, códigos de estado y cabeceras— sigue siendo la base de la web.
¿Qué es el RFC 9110 (Semántica HTTP)?
El RFC 9110 sirve para definir la arquitectura común del Protocolo de Transferencia de Hipertexto (HTTP). Es independiente de la versión del protocolo (HTTP/1.1, HTTP/2 o HTTP/3). Si quiere saber qué significa realmente un 403 Forbidden o cómo debe comportarse una solicitud POST frente a una PUT, el RFC 9110 es la fuente de verdad.
Proporciona un vocabulario consistente para:
- Recursos e Identificadores de Recursos Uniformes (URIs).
- Mensajes (Solicitudes y Respuestas).
- Métodos (GET, POST, etc.).
- Códigos de estado (200, 404, etc.).
- Campos de cabecera.
Principios Core de la Semántica HTTP
1. Métodos de Solicitud e Idempotencia
Uno de los conceptos más importantes en el RFC 9110 es la distinción entre métodos Seguros e Idempotentes.
| Método | Seguro | Idempotente | Descripción |
|---|---|---|---|
| GET | Sí | Sí | Recupera datos sin efectos secundarios. |
| HEAD | Sí | Sí | Igual que GET pero no devuelve cuerpo. |
| PUT | No | Sí | Reemplaza un recurso; repetirlo no tiene más efecto. |
| DELETE | No | Sí | Elimina un recurso. |
| POST | No | No | Procesa datos; múltiples solicitudes pueden crear múltiples recursos. |
2. Clases de Códigos de Estado
El RFC 9110 organiza los códigos de estado en cinco clases:
- 1xx (Informativos): Solicitud recibida, continuando el proceso.
- 2xx (Exitosos): La acción fue recibida, entendida y aceptada.
- 3xx (Redirección): Se deben tomar más acciones para completar la solicitud.
- 4xx (Error del Cliente): La solicitud contiene sintaxis errónea o no se puede cumplir.
- 5xx (Error del Servidor): El servidor falló al cumplir una solicitud aparentemente válida.
Escenarios de Aplicación Práctica
Diseño de APIs RESTful
Seguir el RFC 9110 asegura que su API sea "descubrible" y se comporte como esperan los clientes y cachés HTTP estándar. Por ejemplo, usar 201 Created tras un POST exitoso en lugar de un genérico 200 OK.
Optimización de Caché
El RFC 9110 define cómo funcionan las cabeceras Vary, ETag y Last-Modified. Una implementación correcta permite que las CDNs y los navegadores almacenen datos de forma eficiente, reduciendo la carga del servidor.
Negociación de Contenido
El protocolo permite que un cliente solicite un formato específico (ej. Accept: application/json) y el servidor responda con la mejor representación disponible.
Comparación: RFC 7231 vs. RFC 9110
El RFC 9110 no cambió fundamentalmente cómo funciona HTTP, pero mejoró la documentación significativamente:
- Consolidación: Fusionó la semántica de múltiples documentos en uno solo.
- Claridad: Aclaró puntos ambiguos respecto al contenido parcial (solicitudes de rango) y la autenticación.
- Versionado: Separa explícitamente el "qué" (Semántica) del "cómo" (HTTP/1.1 vs HTTP/3).
FAQ
P: ¿El RFC 9110 es solo para HTTP/1.1?
R: No. El RFC 9110 define la semántica que se aplica a todas las versiones de HTTP, incluyendo HTTP/2 y HTTP/3.
P: ¿Cuál es la diferencia entre POST y PUT?
R: Según el RFC 9110, PUT es idempotente (reemplaza el recurso en una URI específica), mientras que POST no lo es (envía datos para ser procesados).
P: ¿Cuándo debo usar un 403 frente a un 401?
R: Use 401 Unauthorized cuando se requiere autenticación y esta ha fallado o no se ha proporcionado. Use 403 Forbidden cuando el servidor entiende la solicitud pero se niega a autorizarla (incluso con credenciales válidas).
Herramientas Relacionadas
- Formateador JSON - Perfecto para inspeccionar respuestas JSON de sus APIs.
- Codificador/Decodificador de URL - Esencial para preparar URIs válidas.
- Decodificador JWT - Decodifica tokens que suelen ir en la cabecera
Authorization.