Quando l’app mobile, il sito e un partner esterno chiamano servizi diversi, ogni modifica interna rischia di costringere anche i client ad aggiornarsi. Un API gateway offre un punto d’ingresso comune e di solito semplifica il traffico, ma il risultato dipende da quali responsabilità gli affidi.
Il gateway semplifica l’accesso, ma va dimensionato e delimitato
- Un solo ingresso: instrada le richieste verso i servizi senza esporre ai client la topologia interna.
- Compiti adatti: autenticazione, limiti di traffico, terminazione TLS e logging possono essere centralizzati.
- Confine di sicurezza: il gateway non sostituisce i controlli di autorizzazione sui singoli dati e sulle operazioni.
- Scelta architetturale: un gateway condiviso è semplice da governare; un BFF può adattare l’API alle esigenze di ciascun client.
- Controllo operativo: testa latenza, gestione dei picchi e comportamento in caso di errore prima di esporre il servizio.
Il gateway nasconde la topologia interna ai client
Immagina che una schermata di pagamento debba consultare ordini, profilo e disponibilità. Senza un livello intermedio, il client deve conoscere gli endpoint dei diversi servizi e gestire direttamente ogni variazione. Un gateway riceve la richiesta pubblica e la instrada verso il backend appropriato, mantenendo separato ciò che vede il client da come sono organizzati i sistemi interni.
Può anche applicare regole comuni, per esempio verificare credenziali, terminare la connessione TLS o registrare i metadati della richiesta. Se una singola operazione richiede più servizi, può aggregarne le risposte: così il client fa meno chiamate, anche se il gateway deve gestire la logica di composizione. Le responsabilità e i limiti di questo schema sono descritti nel Microsoft Azure Architecture Center.
Il vantaggio, quindi, non è “avere un URL solo” in astratto: è ridurre l’accoppiamento tra interfacce e backend. Se i client non devono conoscere i confini interni dei servizi, il gateway può rendere più semplici le evoluzioni successive.
Un gateway condiviso e un BFF risolvono esigenze diverse
Un unico ingresso sembra ordinato finché web, app mobile e integrazioni esterne hanno bisogni simili. Quando ciascun client richiede dati e flussi differenti, un gateway centrale rischia di accumulare eccezioni e trasformazioni specifiche. In quel caso, un BFF (Backend for Frontend) offre un livello dedicato a un tipo di client, come l’app mobile.
La distinzione è pratica: il gateway condiviso è adatto a funzioni trasversali e routing uniforme; il BFF ha senso quando l’esperienza di un client richiede una composizione diversa o risposte più adatte alle sue schermate. La documentazione Microsoft sul pattern API gateway e Backend for Frontend descrive questa separazione.
Io preferirei partire da un gateway condiviso per le policy comuni e aggiungere un BFF solo quando un client presenta esigenze autonome e ricorrenti. Creare subito livelli distinti per ogni applicazione può moltiplicare deploy e configurazioni prima che esista un problema concreto da risolvere.
Il limite di richieste protegge il servizio, ma non garantisce un tetto rigido
Un picco di chiamate può saturare il backend prima che il team riesca a intervenire. Il rate limiting consente di limitare la frequenza delle richieste, spesso usando un token bucket: un contatore si ricarica nel tempo e ammette una raffica temporanea entro la capacità configurata.
C’è però un dettaglio che cambia la progettazione: nella documentazione di Amazon API Gateway, le soglie di throttling sono descritte come obiettivi applicati “best effort”, non come massimali garantiti. Quando le richieste superano rate e burst, il client può ricevere 429 Too Many Requests. Perciò una policy sul gateway aiuta a controllare il flusso, ma non sostituisce capacità sufficiente nel backend né una strategia di retry prudente.
Nel client, un retry immediato e ripetuto può aggravare proprio il sovraccarico che ha provocato il 429. La risposta va gestita con attese e limiti di tentativi, mentre il gateway e i servizi devono condividere una politica coerente. Non presentare una soglia configurata come garanzia matematica se il servizio la definisce come best effort.
Autenticare una chiamata non autorizza ogni operazione
Un token valido dimostra che una richiesta arriva da un’identità autenticata; non dimostra che quell’identità possa leggere o modificare qualunque risorsa. Se un endpoint riceve l’identificativo di un ordine, il servizio deve comunque verificare che quell’ordine appartenga all’utente o al tenant che effettua la chiamata.
La distinzione emerge chiaramente nei rischi elencati da OWASP API Security Top 10 2023: il controllo degli accessi a livello di oggetto e quello a livello di funzione sono categorie distinte. Un gateway può applicare controlli generali, ma il servizio che conosce il dato e la regola di business deve verificare i permessi specifici.
La tabella aiuta a capire dove intervenire quando il comportamento non è quello atteso:
| Situazione | Possibile causa o conseguenza | Cosa fare |
|---|---|---|
| Risposta 401 | Credenziali assenti, non valide o scadute | Controllare il token e il meccanismo di autenticazione configurato sul gateway. |
| Risposta 403 su una risorsa specifica | Identità riconosciuta, ma permessi insufficienti | Verificare l’autorizzazione nel servizio, inclusa la relazione tra utente e oggetto richiesto. |
| Risposta 429 durante un picco | È stato superato un limite di frequenza o di burst | Ridurre o distribuire i retry e confrontare le soglie del gateway con la capacità del backend. |
| Un solo gateway rallenta o non risponde | Il livello d’ingresso può diventare collo di bottiglia o punto singolo di guasto | Verificare replica, bilanciamento, health check e comportamento durante il failover. |
Un’API pubblica richiede anche inventario e controlli regolari: endpoint dimenticati o non documentati possono restare esposti senza che il gateway corregga automaticamente la lacuna. Centralizzare il traffico rende più gestibili le policy, non rende sicuro per definizione il backend.
La scelta si decide con un test sul percorso completo
Un gateway introduce un passaggio di rete e un componente da mantenere. Il suo costo prestazionale può essere contenuto, ma va misurato sul percorso reale: client, gateway, servizi chiamati e risposta aggregata. La guida Microsoft segnala sia la latenza aggiuntiva sia il rischio che un gateway non scalato adeguatamente diventi un collo di bottiglia.
Prima di adottarlo o sostituirlo, prova almeno questi casi: richiesta normale, picco di traffico, backend lento, credenziale scaduta e indisponibilità di un servizio. Registra la latenza complessiva, la quota di errori e il comportamento dei retry; un test limitato alla risposta “200 OK” non mostra cosa succede quando una dipendenza si guasta.
La decisione può essere semplice: se devi esporre pochi endpoint stabili e il client può chiamarli direttamente in sicurezza, il gateway potrebbe aggiungere complessità senza vantaggi proporzionati. Se invece più client devono raggiungere molti servizi e applicare politiche comuni, un gateway gestito o una soluzione integrata nella piattaforma può essere il punto di partenza più sobrio; un livello personalizzato ha senso quando le opzioni disponibili non coprono requisiti reali di controllo o flessibilità.
Parti dal contratto, poi aggiungi il livello d’ingresso
Prima di configurare rotte e policy, definisci quali API sono pubbliche, chi può invocarle e quali dati può ottenere ogni identità. Un contratto esplicito, per esempio descritto con OpenAPI, aiuta a distinguere l’interfaccia esterna dalla struttura dei servizi e rende più verificabili le modifiche.
Il gateway funziona meglio quando ha confini chiari: centralizza l’infrastruttura condivisa, lascia ai servizi le regole sui dati e testa i guasti lungo l’intero percorso. Così il client trova una porta d’ingresso stabile, senza trasformarla in un nuovo punto fragile dell’architettura.