Cos'è un API gateway e quando conviene introdurlo?

Un API gateway è il livello software che si inserisce tra i client esterni (applicazioni, partner, dispositivi) e le API di un sistema, e ne governa l'accesso in un unico punto invece che dentro ogni singolo servizio. Concentra le funzioni che altrimenti andrebbero riscritte identiche in ogni endpoint: autenticazione e autorizzazione, rate limiting per impedire che un client saturi il backend, versioning per far convivere client vecchi e nuovi sulla stessa API, gestione del CORS per i client browser, e instradamento verso il servizio corretto. Governa il traffico nord-sud, quello che entra dall'esterno del sistema, e va tenuto distinto dal service mesh, che governa il traffico est-ovest fra i servizi interni: sono due strati della stessa architettura, spesso confusi nella stessa conversazione perché condividono alcune funzioni (routing, retry) ma risolvono ciascuno un problema realmente diverso.

Cosa consolida, e perché è la scelta anti-frammentazione

Senza un gateway, ogni servizio che espone un'API pubblica finisce per implementare la propria versione di autenticazione, dei propri limiti di frequenza e della propria policy CORS, con il risultato che la stessa regola di sicurezza vive in dieci posti diversi e cambia in modo incoerente quando qualcuno la aggiorna in uno solo. Il gateway sposta queste responsabilità in un unico strato che si configura e si aggiorna una volta sola, e ci aggiunge spesso due funzioni che un load balancer da solo non offre: la trasformazione di richiesta e risposta per adattare formati eterogenei fra client e backend, e l'aggregazione di più chiamate verso servizi diversi in un'unica risposta al client, oltre al circuit breaking verso i servizi a monte quando uno di loro degrada. Il rovescio della medaglia è un singolo punto di controllo che, se mal dimensionato o mal configurato, diventa un collo di bottiglia per tutto il traffico in ingresso, e se non ridondato un singolo punto di guasto per l'intero sistema esposto: la disciplina operativa di alta disponibilità che serve a un database o a un load balancer si applica allo stesso modo al gateway, non è opzionale solo perché sta più in alto nello stack. Va messo in conto anche l'hop di rete in più che il gateway introduce su ogni chiamata, un costo di latenza fisso e non solo un rischio quando il traffico cresce.

Un esempio enterprise

Un'azienda che espone le proprie API a tre canali diversi (app mobile, portale partner B2B, integrazioni di clienti enterprise) ha bisogno di applicare limiti di frequenza diversi per canale, senza toccare il codice dei servizi che quelle API implementano: il portale partner deve reggere un volume prevedibile e concordato via contratto, mentre le integrazioni enterprise possono avere picchi imprevisti da assorbire con una coda invece che con un errore. Con un gateway, questa policy si scrive in un unico punto di configurazione e si applica prima che la richiesta raggiunga il servizio. Senza, ogni team che possiede un servizio deve implementare e mantenere la propria versione della stessa logica, con il rischio concreto che due team la implementino in modo diverso e producano un comportamento incoerente per lo stesso cliente su API diverse.

Perché conta per chi decide

La domanda da fare prima di introdurre un gateway non è se serva un punto di ingresso, quasi ogni sistema con più di un servizio esposto ne trae beneficio, ma quanta della logica di frontiera (autenticazione, limiti, versioning) è oggi duplicata e quanto costa mantenerla duplicata rispetto al costo operativo di un nuovo strato da presidiare. Va anche tenuto distinto dall'AI gateway, che risolve lo stesso problema di controllo centralizzato ma per il traffico verso i modelli linguistici (chiavi, quote, costi per token, filtri di sicurezza specifici dell'AI): un'azienda che ha già un API gateway generico non ha automaticamente risolto il governo del traffico verso i modelli, perché le due categorie di rischio e le due metriche da controllare non si sovrappongono.