Piattaforme / 01
API REST disponibile. Serve l’integrazione.
La documentazione è disponibile e una richiesta di test funziona. Nell’uso quotidiano mancano comunque dati o si generano duplicati. DataSource collega la vostra API REST al processo aziendale concreto e pianifica anche il caso in cui la risposta non arrivi.
La situazione iniziale
Una richiesta riuscita è solo l’inizio.
Un portale deve importare clienti da un ERP. I sistemi utilizzano ID e campi obbligatori differenti. L’ERP restituisce risultati paginati, il portale limita le scritture. Un export manuale nasconde queste differenze ma non le risolve.
Prima dell’implementazione verifichiamo versione API supportata, volumi, aggiornamento richiesto e contratto di destinazione. Un documento OpenAPI aiuta; risposte reali anonimizzate ed errori sono altrettanto importanti.
Cosa gestisce DataSource
Contratto dei dati, accesso e ripristino.
Contratto dei dati
Concordare campi sorgenti e di destinazione, identità, tipi di dati e valori obbligatori. Definire regole per valori mancanti e modifiche allo schema.
Accesso e trasferimento
Implementare autenticazione, perimetro delle autorizzazioni e rinnovo dei token secondo l’API. Considerare paginazione, limiti temporali e ordine degli oggetti dipendenti.
Ripristino
Gestire avanzamento del trasferimento e ID esterni per poter riprendere le esecuzioni interrotte. Prima di ripetere una scrittura con risposta incerta, verificare lo stato nella destinazione.
Scenario tecnico / Esempio illustrativo
Riconciliare i clienti senza crearli due volte.
L’esempio mostra un contratto di destinazione proposto. L’ID esterno del cliente è la chiave funzionale. Upsert e meccanismi di idempotenza devono essere supportati dall’API di destinazione o implementati nell’integrazione.
Dati di esempio e regole proposte. Le interfacce e le regole aziendali concrete vengono verificate per il vostro progetto.
PUT /customers/004218
Content-Type: application/json
{
"externalId": "004218",
"name": "Beispiel GmbH",
"countryCode": "AT"
}Gestione degli errori, sicurezza ed esercizio
Classificare correttamente gli errori HTTP.
Rate limit
Con HTTP 429 rispettare le indicazioni dell’API e, se previsto, Retry-After. Pianificare tentativi limitati con backoff; gli errori permanenti di validazione richiedono una correzione.
Conflitti di modifica
Utilizzare ETag o campi di versione quando supportati. Un record modificato nel frattempo non deve essere sovrascritto con uno stato precedente.
Esercizio
Documentare ID di correlazione, contatori e categorie di errore. Token e payload completi con dati personali non devono comparire nei log operativi generali.
Domande funzionali
I dettagli che contano prima dell’implementazione.
HTTP · REST · OAuth · API key · Paginazione · Retry
Ogni API può eseguire un upsert?
No. Alcune offrono solo endpoint separati per Create e Update. L’integrazione richiede quindi un’associazione affidabile e una procedura per i risultati incerti.
Serve il tempo reale?
Dipende dal processo aziendale. Il polling può bastare; i webhook sono utili se la sorgente comunica le modifiche in modo affidabile. Una riconciliazione resta utile per gli eventi mancati.
Cosa succede con una nuova versione dell’API?
Verifichiamo contratti e casi di errore rappresentativi in un ambiente di test. Scadenze di deprecation, passaggio e procedura di ripiego vengono concordati prima della modifica in produzione.
Per il confronto tecnico
Partire dal vostro processo concreto.
Preparate documentazione API, versione, esempi anonimizzati, direzione desiderata e frequenza di aggiornamento. Sono utili i limiti noti e l’indicazione del sistema responsabile di ogni campo.
Nel primo incontro chiariamo accessi disponibili, responsabilità dei dati e un primo flusso circoscritto. Poi concordiamo perimetro, responsabilità e condizioni.
Richiesta di progetto
Quali API devono lavorare insieme?
Descrivete brevemente il processo attuale e il risultato desiderato.
Attività correlate
La prossima connessione nel suo contesto.
Elaborare i webhook in modo affidabile
Un evento arriva e deve attivare un’azione nel sistema successivo. Consegne multiple, ritardi o un’API di destinazione indisponibile trasformano il caso in un processo operativo. Lo sviluppiamo con eventi univoci ed effetti verificabili.
Trasformazione dei dati JSON / XML
I dati sono tecnicamente leggibili ma vengono comunque rifiutati. Nomi dei campi, tipi o strutture non corrispondono all’applicazione di destinazione. Sviluppiamo mapping tracciabili che gestiscono anche valori vuoti, casi particolari e modifiche al formato sorgente.
Sincronizzare i dati tra sistemi
Un cliente viene modificato nel CRM e anche nell’ERP. Quale versione vale? Costruiamo la sincronizzazione su responsabilità funzionali e identità stabili, affinché i trasferimenti periodici non generino conflitti silenziosi.
Riferimenti tecnici
Documentazione ufficiale, verificata il 6 ottobre 2026. L’idoneità dipende dall’installazione e dalla versione specifiche.