Que signifie qu'un endpoint est idempotent, et comment rendriez-vous idempotent un endpoint de création ?

Un endpoint idempotent produit le même résultat qu'il soit appelé une fois ou cinq fois avec la même entrée. GET, PUT et DELETE sont naturellement idempotents ; POST ne l'est pas. On rend un endpoint de création idempotent en faisant envoyer au client une clé d'idempotence unique, en stockant cette clé à côté de la ressource créée dans la même transaction, et en renvoyant le résultat d'origine à chaque répétition.

Idempotent veut dire que l'appeler deux fois laisse le système dans le même état que l'appeler une fois. PUT est idempotent parce que vous énoncez l'état final ; POST ne l'est en général pas, parce que chaque appel veut dire en créer un de plus. Pour un endpoint de création, je fais générer une clé par le client, en général un UUID, et l'envoyer dans un en-tête. Côté serveur, je stocke cette clé dans une table avec une contrainte d'unicité, et je l'écris dans la même transaction que la ressource elle-même, parce que si ces deux validations peuvent diverger tout le dispositif est décoratif. Si la même clé revient, je la retrouve et je renvoie la réponse d'origine avec le statut d'origine. Ce que les gens ratent, c'est le cas concurrent, où deux reprises arrivent dans la même milliseconde. L'index unique s'en occupe : la seconde insertion échoue, j'attrape la violation et je relis le gagnant au lieu de renvoyer une erreur. J'ai construit ça pour un endpoint de paiement après qu'on a facturé quelqu'un deux fois pendant une coupure réseau.