API: cosa sono, come funzionano e perché servono alle imprese
API: cosa sono e come funzionano? Un’API è un contratto che permette a due sistemi software di scambiarsi richieste e risposte secondo regole definite. Il sito può inviare una prenotazione al gestionale, il checkout può chiedere a un provider di autorizzare un pagamento, il CRM può ricevere un nuovo contatto senza copiare i dati a mano.
Per un’impresa, il valore non è “avere un’API”, ma collegare un flusso reale in modo affidabile, sicuro e osservabile. Prima di stimare tempi e costi bisogna capire dati, frequenza, responsabilità e comportamento in caso di errore.
API: cosa sono con un esempio semplice
Immagina un sito che mostra disponibilità per un evento. Il browser chiede al servizio di prenotazione i posti rimasti; il servizio risponde con un dato strutturato. Quando l’utente conferma, una seconda richiesta registra la prenotazione e restituisce un identificativo.
Il sito non deve conoscere il database interno del gestionale. Conosce soltanto le operazioni autorizzate, i dati da inviare e le risposte possibili. Questa separazione consente ai sistemi di evolvere, purché il contratto resti compatibile.
Come funziona una richiesta API
- Client: il sistema che avvia la richiesta, per esempio un sito o un’app.
- Endpoint: l’indirizzo dell’operazione disponibile.
- Metodo: l’intenzione, come leggere, creare, aggiornare o eliminare.
- Autenticazione: la prova che il client può usare il servizio.
- Payload: i dati inviati, spesso in formato JSON.
- Risposta: stato, dati richiesti o dettaglio dell’errore.
In un’API HTTP i metodi più comuni sono GET, POST, PUT/PATCH e DELETE. I codici di stato aiutano a distinguere successo, richiesta non valida, assenza di autorizzazione, risorsa non trovata ed errore del server.
API REST, GraphQL e webhook
| Approccio | Quando è utile | Attenzione |
|---|---|---|
| REST | Risorse e operazioni chiare, ampia compatibilità | Coerenza di endpoint, versioni e paginazione |
| GraphQL | Client che richiedono combinazioni variabili di dati | Autorizzazione, complessità e controllo delle query |
| Webhook | Notificare eventi senza interrogazioni continue | Firma, retry, duplicati e ordine degli eventi |
Non sono alternative assolute. Un sistema può usare REST per le operazioni e webhook per notificare pagamenti, prenotazioni o aggiornamenti. La scelta dipende dal flusso, non dalla moda tecnica.
Esempi di API per un’impresa
- Prenotazioni: sincronizzare disponibilità, clienti, conferme e annullamenti.
- CRM: creare contatti dal sito e aggiornare stato e consenso.
- Pagamenti: autorizzare transazioni e ricevere esiti firmati.
- Gestionale/ERP: scambiare prodotti, giacenze, ordini e fatture.
- Marketing: inviare conversioni, segmenti e preferenze.
- Logistica: creare spedizioni, etichette e tracking.
- Identità: consentire accesso con un account centrale.
Prima dell’integrazione mappa il processo attuale. Automatizzare un passaggio ambiguo può aumentare duplicati ed errori anziché ridurli.
Il contratto: dati, significato e versioni
Una documentazione utile descrive endpoint, campi, tipi, obbligatorietà, esempi, errori, limiti e autenticazione. La OpenAPI Specification permette di rappresentare in modo standard molte API HTTP e può supportare documentazione, test e generazione di client.
La sintassi non basta. I sistemi devono condividere il significato: “cliente attivo”, “prezzo”, “disponibile” o “data di consegna” possono avere definizioni differenti. Documenta mapping, fonte autorevole e regole di aggiornamento.
Autenticazione e autorizzazione
Una chiave API identifica spesso l’applicazione, mentre token e protocolli come OAuth possono rappresentare utenti e permessi. In ogni caso applica il minimo privilegio: un’integrazione che deve leggere disponibilità non dovrebbe poter cancellare ordini.
Conserva segreti fuori dal codice e dal browser, ruotali, limita origini e reti quando possibile e registra gli accessi. Usa HTTPS e valuta la protezione dei dati personali lungo l’intero flusso, non solo sul sito pubblico.
Errori, retry e idempotenza
Reti e servizi falliscono. Un timeout non dice sempre se l’operazione sia avvenuta. Se il client ripete una richiesta di pagamento o prenotazione senza protezioni, può creare duplicati.
L’idempotenza permette di ripetere una richiesta con la stessa chiave senza produrre un secondo effetto. I retry devono usare attese progressive, limiti e una coda per gli errori non risolvibili. Ogni fallimento importante deve avere un proprietario e una procedura.
Limiti, paginazione e prestazioni
Le API possono limitare il numero di richieste per proteggere il servizio. Il client deve rispettare rate limit e intestazioni, usare cache quando appropriato e recuperare grandi elenchi con paginazione.
Non trasferire più dati del necessario e non eseguire una chiamata per ogni riga quando è disponibile un’operazione batch. Prestazioni e costi dipendono anche dalla frequenza e dal volume, non solo dal numero di endpoint.
Monitoraggio e osservabilità
Registra durata, stato, identificativo di correlazione e risultato, evitando dati sensibili nei log. Crea metriche per errori, retry, code ferme e tempi di sincronizzazione. Un allarme tecnico deve tradursi in impatto: ordini non importati, pagamenti in attesa o disponibilità non aggiornata.
Prevedi una riconciliazione periodica tra sistemi. Anche un’integrazione apparentemente riuscita può perdere o duplicare record nel tempo.
Quanto costa integrare un’API
Il costo dipende da qualità della documentazione, autenticazione, numero di flussi, trasformazione dei dati, ambiente di test, errori, vincoli del fornitore e responsabilità operative. Una connessione semplice e ben documentata può richiedere pochi giorni; un’integrazione bidirezionale con dati storici e casi eccezionali può diventare un progetto.
Considera costi ricorrenti: canoni API, manutenzione, monitoraggio, aggiornamenti di versione e supporto. La dipendenza da un servizio esterno va valutata anche in termini di continuità e possibilità di uscita.
Domande da fare prima di iniziare
- Quale evento aziendale avvia il flusso?
- Quale sistema è autorevole per ogni dato?
- Quali operazioni e permessi sono realmente necessari?
- Esiste un ambiente di test con dati rappresentativi?
- Come vengono gestiti errori, duplicati e operazioni parziali?
- Quali limiti, costi e SLA applica il fornitore?
- Come verranno monitorati e riconciliati i dati?
- Che cosa accade se l’API cambia o non è disponibile?
Checklist: API cosa sono e come funzionano
- Il processo aziendale è mappato prima del codice?
- Contratto e significato dei dati sono documentati?
- Permessi e segreti seguono il minimo privilegio?
- Retry e idempotenza proteggono le operazioni critiche?
- Rate limit, paginazione e volumi sono stimati?
- Log, metriche e riconciliazione rendono visibili gli errori?
- Versioni, manutenzione e uscita sono previste?
Per approfondire i concetti del web e del protocollo HTTP, consulta anche MDN Web Docs. Se vuoi collegare sito, CRM, pagamenti, prenotazioni o gestionale, scopri i miei servizi di sviluppo web oppure richiedi un confronto.