Del clic a la respuesta

Un teatro ficticio vende asientos desde un sitio adaptado al teléfono. Tocas «Reservar», aparece un indicador de espera y después una confirmación. Esa experiencia sencilla oculta varias decisiones. Saber dónde ocurren permite entender por qué navegador, servicio y base de datos no pueden confiar sin más en las suposiciones de los demás.

El clic inicia trabajo en el cliente

El navegador puede enviar un formulario o ejecutar JavaScript para preparar una solicitud. La página puede generarse en el servidor, construirse en el navegador o combinar ambos métodos. Un clic puede causar varias solicitudes, y algunas interacciones no necesitan ninguna. La apariencia no revela por sí sola la arquitectura del sistema.

HTTP asigna a las solicitudes un método, destino, cabeceras y, en ciertos casos, contenido. Las respuestas llevan estado, cabeceras y posiblemente contenido. La aplicación decide cómo esos mensajes corresponden a sus operaciones. Decir que algo es una API indica que ofrece una interfaz para software; no explica quién puede usar cada operación.

El servicio receptor toma la decisión

Las comprobaciones del cliente ayudan a corregir un formulario vacío. El servicio sigue teniendo que validar lo recibido, establecer la identidad relevante y comprobar permisos para la acción y el objeto. Elegir un asiento y cancelar una reserva ajena plantean preguntas de autorización distintas, aunque ambas solicitudes tengan un formato válido.

El precio y la disponibilidad deben proceder del estado autoritativo cuando se confirma la reserva. Dos personas pueden ver el mismo asiento disponible simultáneamente. La operación de datos debe impedir que ambas lo consigan, mediante reglas apropiadas de transacciones o concurrencia. Una página que se ve correcta no resuelve por sí sola ese conflicto.

PrediceEl servicio confirma una reserva, pero la conexión se interrumpe antes de que llegue la confirmación al teléfono. ¿Demuestra su ausencia que no existe reserva?

No. El cliente tiene un resultado incierto. La aplicación necesita recuperar el resultado y gestionar los reintentos sin crear otra reserva accidentalmente. Un tiempo de espera agotado describe lo observado por el cliente, no todo lo realizado por el servidor.

Las respuestas tienen distintos orígenes

La descripción pública de un evento puede reutilizarse desde una caché del navegador o compartida. El resultado privado de una reserva necesita reglas acordes con su sensibilidad y destinatarios. El cifrado no elige automáticamente la política de caché. Una CDN o un proxy inverso puede responder o reenviar, y la aplicación puede dejar tareas posteriores en una cola.

El trabajador que envía el correo debe recibir solo los datos y permisos necesarios. Su éxito tampoco es el mismo que el de la reserva: el asiento puede quedar reservado aunque el correo se retrase. Los mensajes al usuario deben distinguir esos resultados.

Lee el resultado completo

Un código de estado aporta evidencia, pero no explica todo el resultado del negocio. También importan el contenido de la respuesta y el estado de la aplicación. Sigue por separado entrada, identidad, permiso, cambio de datos y presentación. Estas responsabilidades siguen existiendo con una máquina, muchos contenedores o servicios gestionados de nube.