Reintentar sin repetir consecuencias

Una confirmación ausente no demuestra una reserva ausente.

Repetir la intención, no el efecto

La idempotencia significa que repetir una operación tiene el mismo efecto previsto que realizarla una vez. Las respuestas y los registros de diagnóstico pueden diferir. HTTP define métodos idempotentes, pero un flujo que crea reservas necesita su propio contrato de reintentos; usar POST no lo proporciona automáticamente.

Un diseño habitual vincula un identificador de operación, dentro del ámbito de cada persona, con los detalles y un resultado duradero. Repetirlo debe significar la misma operación, no otra solicitud que comparte una etiqueta.

Registro ficticio de reservas

La política conserva registros de reintentos durante 24 horas. Estas observaciones se proporcionan para revisarlas:

• I1: A las 10:00, la operación R8 de Lina crea B41. Se pierde la respuesta de confirmación.
• I2: A las 10:01, la misma persona y R8, con iguales detalles, reciben el resultado registrado de B41. Sigue existiendo una sola reserva.
• I3: Hay dos entradas de diagnóstico porque llegaron dos intentos.

Qué respalda el registro

I2 respalda un único efecto en esta observación. I3 no lo contradice: dos intentos no son dos reservas. No demuestra el comportamiento ante intentos simultáneos, fallos al guardar o reintentos fuera del plazo.

La aprobación necesita coordinar el registro del identificador y la confirmación de la reserva para que un fallo no los separe. Cambiar detalles con el mismo identificador debe producir un conflicto definido, no otra reserva silenciosa. Devolver un resultado guardado sigue requiriendo autorización.

Límite: Un reintento correcto respalda el ejemplo; no establece una garantía ilimitada de entrega exactamente una vez.