Le differenze tra API sincrone e asincrone

Le API (Application Programming Interface) funzionano secondo un modello richiesta-risposta: in una chiamata API, il client invia una request al server e quest’ultimo gli risponde fornendo i dati richiesti oppure un messaggio. Questo schema generale può essere declinato in due modalità di esecuzione: sincrona e asincrona. 

La distinzione tra questi due modelli non è soltanto teorica, ma influisce notevolmente sulla progettazione di sistemi scalabili ed efficienti, motivo per cui la corretta implementazione di meccanismi di interazione sincroni e asincroni è una caratteristica fondamentale di ogni architettura applicativa moderna.

API sincrone: cosa sono e come funzionano

In un’API sincrona, la comunicazione avviene in tempo reale: il client invia la richiesta al server e aspetta fino a che non riceve la risposta. Nel tempo che intercorre tra la richiesta e la sua esecuzione, il client non può eseguire altre operazioni né inviare nuove richieste sullo stesso thread, perciò si parla anche di meccanismo “bloccante”.

Questo tipo di API è ideale per operazioni veloci, come il recupero di dati di geocoding per la navigazione satellitare o l’aggiornamento di un database condiviso. La risposta del server è praticamente immediata, e in generale contiene i dati richiesti o la conferma dell’esecuzione di un certo comando, per esempio l’eliminazione di una risorsa o l’inoltro di un messaggio. 

Le API sincrone sono molto comuni nei microservizi web, poiché permettono un feedback immediato e sono semplici da implementare. D’altro canto, questo modello di comunicazione prevede che il client attenda la risposta del server prima di poter fare qualunque altra cosa. Ciò significa che è adatto soltanto quando l’elaborazione della risposta richiede pochissimi secondi. In alcune applicazioni, per esempio il caricamento e l'analisi di un video di grandi dimensioni o la generazione di un report finanziario, questo meccanismo può diventare poco efficiente e trasformarsi in un ostacolo per la scalabilità dei sistemi.

Cosa sono le API asincrone?

A differenza delle API sincrone, le API asincrone operano secondo un modello di richiesta-accettazione-notifica: quando il client invia la richiesta, il server risponde confermando di aver preso in carico l’operazione. Il codice di risposta tipico è “202 Accepted”, e generalmente la risposta contiene anche un ID che servirà per ottenere il risultato finale quando sarà pronto. A quel punto, il client è libero di gestire altre richieste (si parla appunto di meccanismo “non bloccante”). 

Quando il server avrà elaborato la risposta, la trasmetterà al client. Ciò può avvenire in due modi:

• Polling: il client interroga lo stato del server periodicamente, finché non trova la risposta (modello Pull);
• Callback / Webhook: quando la risposta è pronta, il server chiama un URL del client avvisandolo del completamento dell’operazione (modello Push).

Le API asincrone sono essenziali in tutti quegli scenari in cui si prevedono tempi di risposta piuttosto lunghi, come può avvenire nel caso dell’elaborazione di video e documenti. Il vantaggio principale legato a questa scelta architettonica è la totale assenza di tempi di attesa, che permette di sfruttare al meglio potenza di calcolo e di rete. D’altro canto, i flussi asincroni sono più complessi da configurare, poiché richiedono tra le altre cose la gestione delle notifiche.

Le differenze tra API sincrone e asincrone

Volendo riassumere le differenze tra API sincrone e asincrone, possiamo dire che riguardano:

• Flusso di lavoro: mentre le API sincrone bloccano il client in attesa della risposta, quelle asincrone gli lasciano i riferimenti per “ritirare” la risposta e lo liberano immediatamente;
• Applicazioni: le API sincrone sono perfette per operazioni brevi e veloci, mentre quelle asincrone sono la soluzione da preferire per tutte le elaborazioni che richiedono più di qualche millisecondo e nelle operazioni che richiedono code di lavoro;
• Consegna della risposta: nelle API sincrone la risposta viene consegnata immediatamente, in quelle asincrone la consegna avviene tramite meccanismi di notifica successivi (polling o callback);
• Complessità: le API asincrone sono più complesse da implementare, poiché devono poter gestire lo stato dell’operazione nel tempo e richiedono meccanismi di notifica che vanno condivisi con il client (che per esempio deve gestire i cicli di polling o esporre un endpoint per la callback).

Molte applicazioni moderne utilizzano architetture ibride in cui vengono usate API sincrone e asincrone a seconda delle esigenze. In qualunque e-commerce, per esempio, operazioni come la verifica del carrello e l’autorizzazione del pagamento utilizzeranno una comunicazione sincrona, mentre le operazioni successive, come la conferma dell’ordine tramite email e la creazione della fattura, avvengono in modalità asincrona.

Quando usare le API sincrone e asincrone

La scelta tra API sincrone e asincrone dipende fondamentalmente dal tempo di esecuzione dell’operazione e dalla necessità di risposta immediata da parte del client. Se il client per esempio necessita della risposta prima di procedere, è bene valutare la comunicazione sincrona. Dei casi tipici sono i processi di autenticazione, in cui il server deve immediatamente verificare le credenziali dell’utente, e il recupero dei dati in tempo reale necessario, per esempio, per il caricamento delle immagini o per il recupero dei metadati di un prodotto in una pagina e-commerce. 

Le API asincrone sono una scelta obbligata per ogni operazione la cui elaborazione richieda più di pochi millisecondi. Alcuni esempi comuni sono l’elaborazione di file di grandi dimensioni, la cui conversione o importazione può avvenire in background mentre il client fa altro, e l’invio di posta massiva, che viene preso in carico immediatamente e gestito nel corso del tempo.

Se l’elaborazione può avvenire in background, senza tenere bloccato il client nell’attesa, e non c’è bisogno di un riscontro immediato, l’architettura asincrona è sicuramente la scelta più efficiente, soprattutto in ambienti che gestiscono molte risorse, per esempio nelle piattaforme di trading in borsa, dove l'aggregazione di dati storici richiede tempo ma non deve bloccare le operazioni in tempo reale.