Inserire due volte gli stessi dati costa ogni giorno.

Nuovi tentativi, ordine e verifica funzionale

Dopo un timeout, un'interfaccia non può sempre riconoscere se la controparte ha già elaborato un ordine. Ripetere ciecamente il tentativo può quindi generare registrazioni doppie. Per le operazioni in scrittura stabiliamo come un identificativo univoco associ le richieste ripetute e per quanto tempo questa informazione resti disponibile. L'identificativo da solo non basta: l'elaborazione e la memorizzazione del risultato devono essere coerenti con il modello delle transazioni.

Per gli eventi consideriamo inoltre l'ordine e la consegna in ritardo. Una cancellazione può arrivare prima che un servizio a valle abbia elaborato l'ordine originale. I cambi di stato consentiti e le informazioni di versione aiutano a gestire questi casi sul piano funzionale. Le code di errore necessitano di una responsabilità assegnata e di un riavvio controllato. Un allineamento periodico dei dati importanti individua differenze che un semplice monitoraggio delle risposte HTTP riuscite non rileva.

Evolvere i contratti senza sorprendere i team collegati

Un contratto API descrive, oltre ai tipi di dati, anche il significato, i casi di errore e i limiti. Chiariamo se un campo mancante, un valore vuoto e una cancellazione esplicita rappresentino operazioni diverse. Gli importi in denaro necessitano di valuta e regole di arrotondamento, le indicazioni temporali di un riferimento univoco. Per grandi quantità di dati, la paginazione, le possibilità di filtro e un ordinamento stabile fanno parte del contratto. Le richieste di esempio rendono queste regole verificabili per i consumer.

Anche modifiche apparentemente additive possono essere problematiche se un client accetta solo valori noti. Per questo censiamo i consumer e verifichiamo le modifiche rispetto alle loro aspettative. Per le nuove versioni prevediamo un percorso di transizione con documentazione, possibilità di test e piano di dismissione. Per i webhook vengono definiti il controllo dell'origine e la gestione delle consegne multiple. Una cronologia di integrazione tracciabile aiuta il supporto a seguire un'operazione di business concreta attraverso più sistemi.

Limitare i guasti e controllare gli accessi dei partner

Un sistema di destinazione lento non deve generare un numero illimitato di connessioni in attesa in tutti i servizi a monte. Pianifichiamo timeout, un numero limitato di nuovi tentativi e limiti di capacità adeguati al processo di business. Alcune attività possono essere memorizzate temporaneamente, altre devono fallire con un riscontro comprensibile. Il valore sostitutivo di un servizio non disponibile non deve far apparire un'informazione come aggiornata o approvata.

Per i partner e le applicazioni gli accessi vengono assegnati separatamente e resi revocabili. La sola limitazione della frequenza non impedisce un accesso ai dati non autorizzato: vengono verificate anche le autorizzazioni a livello di business. I log devono rendere analizzabili gli errori, senza diffondere credenziali o dati sensibili completi. Il passaggio di consegne comprende quindi anche il rinnovo degli accessi, l'allarme in caso di accumulo in coda e una procedura per rielaborare in modo mirato i messaggi difettosi.