Los desafíos reales de la idempotencia en APIs van más allá delsimple uso de claves de idempotencia. Aunque el patrón básico (agregar una clave, almacenar la respuesta y replay en reintentos) funciona para el camino feliz, la complejidad surge cuando la segunda solicitud llega en diferentes estados: mientras la primera aún está en ejecución, después de un crash antes de publicar un evento, o con contenido diferente. El caso más problemático es cuando la misma clave lleva consigo un comando diferente, como solicitar 10 EUR en la primera solicitud y 100 EUR en la segunda. El artículo propone que el servidor debe tener una opinión clara sobre estas situaciones: devolver la respuesta stored, rechazar el request, o tratar la combinación de clave más contenido como una nueva identidad. Se sugiere que una clave reutilizada con un comando diferente debería ser un error duro para APIs con side-effects, ya que devolver la respuesta original oculta bugs serios en el cliente. El diseño propuesto incluye una tabla de idempotency_requests con campos para ownership, request_hash, status, y respuestas almacenadas, permitiendo manejar estados como IN_PROGRESS, COMPLETED, FAILED_REPLAYABLE, y UNKNOWN_REQUIRES_RECOVERY.
Idempotencia en APIs: los casos extremos que complican su implementación
