Resumen

  • Una petición BREW o POST con cuerpo start documenta una instrucción recibida por el servidor; no documenta que el mecanismo físico terminara ni que una taza llegara a alguien.
  • Los objetos de RFC 2325 añaden capacidad, estado, nivel, tiempo y temperatura, pero no definen evidencia de entrega, cumplimiento alimentario, aptitud para beber o consumo humano.

El instante engañoso del éxito

En una consola aparece una respuesta satisfactoria. La URI señala la cafetera correcta. El servidor entiende BREW. El cuerpo contiene start. No responde 406 por una adición imposible ni 418 por haber recibido la orden en una tetera. Es tentador anotar: «café preparado».

La anotación cuenta más de lo que la transacción sabe. El servidor puede acreditar que procesó un mensaje. Todavía faltan el accionamiento de la resistencia, el calentamiento, la presencia de agua y café, el paso por el filtro, la llegada a la jarra, el vertido en una taza y la recepción por una persona. Cada paso ocurre en otro punto de control y necesita su propia observación.

RFC 2324, publicado el 1 de abril de 1998, no es un estándar de Internet. Es un documento Informational que satiriza el uso de HTTP para controlar utensilios. Precisamente por exagerar el vocabulario web aplicado a una cafetera deja una lección nítida: una interfaz puede nombrar un efecto físico sin poseer evidencia de que ese efecto sucedió.

La gramática lo muestra. Las órdenes viajan mediante BREW o POST; el servidor debe aceptar ambas de forma equivalente, aunque el texto desaconseja usar POST para provocar acciones. El tipo corregido por las erratas verificadas es message/coffeepot, y el cuerpo solo admite start o stop. El protocolo puede registrar la intención de comenzar. No contiene un comprobante de finalización.

Una negativa precisa no convierte el silencio en éxito

HTCPCP sí define límites de capacidad. Accept-Additions permite pedir leche, jarabe, edulcorante, especias o alcohol. Si el operador no puede satisfacer la combinación, puede devolver 406 y enumerar lo disponible. Si el destinatario es una tetera a la que se pide café, debe responder 418.

Esos códigos mejoran el diagnóstico. El 406 distingue una composición no disponible. El 418 distingue una clase de aparato equivocada dentro del modelo humorístico. Pero un catálogo de fallos conocidos no hace exhaustivo al éxito. Que no llegue 406 no demuestra que el ingrediente acabó en la bebida. Que no llegue 418 no demuestra que hubiera café molido, agua o una jarra colocada.

El campo Safe también tiene un alcance reducido. Informa sobre la seguridad de repetir una petición, quizá condicionada a que el usuario esté despierto. El propio RFC advierte que la seguridad real de la cafetera puede depender de condiciones del cliente. Por tanto, Safe ayuda a decidir una repetición; no certifica higiene, alérgenos, temperatura de servicio, legalidad ni idoneidad para una persona concreta.

La ironía más técnica aparece en GET. El recurso de la cafetera es físico, mientras que los datos devueltos por su URI normalmente no contienen cafeína. Una representación puede estar bien formada y actualizada, pero sigue siendo una representación. No llena la taza.

Los sensores crean una cadena, no una palabra final

El documento compañero, RFC 2325, imagina un MIB de cafetera. Allí aparecen potCapacity, el tipo de aparato, la ubicación, potOperStatus, el nivel, la unidad, la hora programada, el tiempo desde el inicio y la temperatura.

Cada objeto responde a una pregunta distinta. La capacidad dice cuánto soporta el dispositivo incluso cuando está vacío. El estado puede ser off, brewing, holding, other o waiting, pero brewing no indica cuánto líquido se produjo. El nivel necesita una unidad. La temperatura es una lectura local. El tiempo desde el inicio no garantiza que el agua atravesara el café.

Un registro operativo serio tendría que correlacionar esos hechos con el mismo ciclo: petición, aparato, activación, estado, nivel y temperatura. Después aún harían falta una observación de dispensación, la identidad de la taza o recipiente, la entrega al destinatario y cualquier control de seguridad o conformidad aplicable. Si la pregunta final es «¿alguien lo bebió?», ninguna variable del MIB responde.

La ausencia importa tanto como la presencia. RFC 2325 no define un objeto de «taza entregada», «bebida conforme», «apta para beber» o «consumida». Rellenar ese vacío con una lectura holding no es una inferencia prudente; es cambiar el significado del dato.

La reserva de 418 prueba otra cosa

El legado de 418 es real. RFC 9110 lo conserva como código no usado y reservado porque la broma se desplegó lo suficiente como para impedir una reasignación limpia. La comunidad hizo duradero el símbolo.

Esa durabilidad pertenece al registro y al software, no a las cafeteras. Un número reservado demuestra que el espacio compartido de códigos debe evitar ambigüedad. No demuestra cuántas máquinas implementaron HTCPCP, si alguna preparó una bebida ni qué ocurrió con ella. La publicación, la implementación, la ejecución física y el uso humano son capas distintas de realidad.

Fuentes