¿Qué significa que un endpoint sea idempotente y cómo harías idempotente un endpoint de creación?

Un endpoint idempotente produce el mismo resultado tanto si se llama una vez como cinco con la misma entrada. GET, PUT y DELETE son idempotentes por naturaleza; POST no. Un endpoint de creación se vuelve idempotente haciendo que el cliente envíe una clave de idempotencia única, guardando esa clave junto al recurso creado dentro de la misma transacción, y devolviendo el resultado original en cualquier repetición.

Idempotente significa que llamarlo dos veces deja el sistema en el mismo estado que llamarlo una. PUT es idempotente porque estás declarando el estado final; POST normalmente no, porque cada llamada significa crea otro. Para un endpoint de creación hago que el cliente genere una clave, típicamente un UUID, y la envíe en una cabecera. En el servidor guardo esa clave en una tabla con una restricción única, y la escribo en la misma transacción que el recurso, porque si esos dos commits pueden divergir el esquema entero es decorativo. Si vuelve la misma clave, la busco y devuelvo la respuesta original con el estado original. La parte que la gente se salta es el caso concurrente, cuando dos reintentos llegan en el mismo milisegundo. El índice único se encarga de eso: el segundo insert falla, capturo la violación y leo al ganador en vez de dar error. Construí esto para un endpoint de pagos después de que cobráramos dos veces a alguien durante un corte de red.