Gestionar tiempos de espera y reintentos con reglas claras de idempotencia para evitar pedidos y otras operaciones duplicadas.
¿A quién va dirigido? Equipos de desarrollo y responsables de procesos que quieran integrar de forma fiable la escritura de llamadas a la API.
Casos de uso y contexto
Un tiempo de espera no indica con certeza si una operación ha fallado. El servidor puede haber guardado ya el pedido, mientras que la respuesta se pierde en el camino de vuelta. Si la misma llamada se repite sin comprobarlo, pueden producirse pedidos, reservas o notificaciones duplicadas.
En este contexto, idempotencia significa reconocer una solicitud empresarial repetida como el mismo proceso. Para ello, la clave, el periodo de validez y la carga útil deben coincidir. Un identificador aleatorio nuevo cada vez que se repite no resuelve este problema.
El proceso en detalle
- Identificar escrituras críticas. Para cada operación, definir cómo se detecta la igualdad y qué cambios constituyen una nueva petición.
- Vincula un identificador de operación estable a una carga útil validada. Considera llamadas paralelas, conflictos y resultados que ya se han guardado.
- Prueba casos de error: pérdida de respuesta, servidor lento, doble clic y datos modificados bajo el mismo identificador. Proporciona una recuperación de estado clara o una ruta de autorización manual.
Resultados esperados
- Significado definido de una petición repetida
- Protección contra acciones duplicadas no intencionadas
- Estado comprensible en caso de resultado incerto
- Repeticiones limitadas con casos de error documentados
Preparar una decisión informada
Lo que se necesita son contratos de API, cargas útiles típicas y la lista de efectos secundarios irreversibles. Distingue las lecturas seguras de las acciones empresariales de escritura.
Los registros deben correlacionar las operaciones, pero no revelar secretos ni cargas útiles completamente sensibles. La retención de la información de idempotencia debe coincidir con el tiempo de ejecución del proceso y la minimización de datos.
Preguntas y respuestas
¿Se permite que un cliente repita automáticamente tras cada error?
No. La repetibilidad depende del punto final y del error. Sin una idempotencia acordada, una repetición puede crear un segundo caso de negocio.
¿Qué se espera con la misma clave y datos diferentes?
Un conflicto claro suele tener más sentido que una sobreescritura silenciosa. El tratamiento exacto pertenece al contrato de interfaz.