Gestire timeout e nuovi tentativi con regole di idempotenza chiare per evitare ordini o altre operazioni duplicate.
A chi si rivolge? Team di sviluppo e responsabili di processo che vogliono integrare in modo affidabile la scrittura delle chiamate API.
Casi d’uso e contesto
Un timeout non indica con certezza se un'operazione è fallita. Il server potrebbe aver già salvato l'ordine, mentre la risposta si perde al ritorno. Se la stessa chiamata viene ripetuta senza controllo, possono verificarsi ordini duplicati, prenotazioni o notifiche.
In questo contesto, idempotenza significa riconoscere una richiesta aziendale ripetuta come lo stesso processo. Per farlo, la chiave, il periodo di validità e il payload devono corrispondere. Un nuovo identificatore casuale ogni volta che viene ripetuto non risolve questo problema.
Il percorso nel dettaglio
- Identificare le scritture critiche. Per ogni operazione, definire come viene rilevata l'uguaglianza e quali modifiche costituiscono una nuova richiesta.
- Collega un identificatore di operazione stabile a un payload validato. Considera chiamate parallele, conflitti e risultati già salvati.
- Testare i casi di errore: risposta persa, server lento, doppio clic e dati modificati con lo stesso identificatore. Fornire un percorso chiaro di recupero di stato o di autorizzazione manuale.
I risultati attesi
- Significato definito di una richiesta ripetuta
- Protezione contro azioni duplicate involontarie
- Stato comprensibile in caso di esito incerto
- Ripetizioni limitate con casi di errore documentati
Preparare una decisione consapevole
Ciò che serve sono contratti API, payload tipici e la lista degli effetti collaterali irreversibili. Distingui le letture sicure dalle azioni business di scrittura.
I log dovrebbero correlare le operazioni, ma non rivelare segreti o payload completamente sensibili. La conservazione delle informazioni di idempotenza dovrebbe essere abbinata all'esecuzione del processo e alla minimizzazione dei dati.
Domande e risposte
Un client è autorizzato a ripetere automaticamente dopo ogni errore?
No. La ripetibilità dipende dall'endpoint e dall'errore. Senza un'idempotenza concordata, una ripetizione può creare un secondo business case.
Cosa ci si aspetta con la stessa chiave e dati diversi?
Un conflitto chiaro di solito ha più senso di una sovrascrittura silenziosa. Il trattamento esatto appartiene al contratto di interfaccia.