Per garantire la stabilità del sistema, prevenire abusi e mantenere un utilizzo equo tra tutte le integrazioni, InterAction+™ Cloud API implementa solidi meccanismi di Limitazione della Frequenza (Rate Limiting) e Analisi della Complessità. Queste misure aiutano a proteggere da attacchi Denial-of-Service (DoS), assicurano che nessun singolo client possa monopolizzare le risorse dell’API e mantengono un’esperienza costante per tutti gli utenti.
Importanza della Limitazione della Frequenza e dell’Analisi della Complessità
Senza una corretta limitazione della frequenza, le API sono vulnerabili ad abusi, come richieste eccessive da parte di attori malevoli o client mal configurati, che possono portare a un degrado del servizio o alla sua indisponibilità. L’Analisi della Complessità garantisce che query troppo complesse non consumino risorse di sistema in modo eccessivo, influendo sulle prestazioni di InterAction+™ Cloud API. Insieme, questi controlli aiutano a:
- Proteggere da attacchi DoS limitando il volume di richieste provenienti da una singola fonte.
- Garantire un’equa allocazione delle risorse, evitando che un client possa degradare le prestazioni per gli altri.
- Mantenere la stabilità e l’affidabilità del sistema prevenendo sovraccarichi del server causati da traffico eccessivo o query computazionalmente onerose.
Strategia di Limitazione della Frequenza
InterAction+™ Cloud API applica limiti di frequenza utilizzando due approcci diversi:
- Limitazione della Frequenza a Finestra Fissa: Questo metodo suddivide il tempo in intervalli fissi (ad esempio, un’ora o un giorno). Una volta raggiunto il limite all’interno della finestra, tutte le richieste successive vengono rifiutate fino all’inizio dell’intervallo successivo.
- Limitazione della Frequenza a Finestra Mobile: Questo approccio suddivide il periodo di tempo in segmenti più piccoli (ad esempio, dividendo un minuto in sei segmenti da 10 secondi ciascuno) e mantiene un conteggio continuo delle richieste. Questo metodo aiuta a gestire i picchi di traffico mantenendo un conteggio continuo delle richieste invece di azzerare a intervalli fissi. In questo modo, le richieste vengono distribuite in modo più uniforme. Ad esempio, se il limite di un minuto è suddiviso in sei segmenti da 10 secondi, il sistema valuta continuamente gli ultimi 60 secondi invece di ripartire ogni minuto intero. Questo approccio attenua i picchi di traffico, consente un flusso costante e riduce improvvisi sovraccarichi sul server.
Limiti di Frequenza
- La limitazione della frequenza viene applicata su più intervalli temporali per bilanciare le prestazioni e prevenire un uso eccessivo dell’API. I limiti applicati sono:
- 5 richieste al secondo
- 100 richieste al minuto, suddivise in sei segmenti uguali utilizzando un algoritmo a Finestra Mobile per gestire efficacemente i picchi di traffico (~16 richieste ogni 10 secondi).
- 6.000 richieste all’ora (limite fisso)
- 18.000 richieste al giorno (limite fisso)
- Se una richiesta supera il limite di frequenza per qualsiasi intervallo temporale, verrà rifiutata con una risposta HTTP 429 (Troppe richieste).
- Quando applicabile, la risposta includerà il numero di secondi da attendere prima di poter riprovare.
- I limiti di frequenza vengono applicati in modo indipendente per ogni connessione unica, definita come combinazione di Third-Party Client e Tenant.
Analisi della Complessità
Per evitare un consumo eccessivo di risorse del server dovuto a query GraphQL complesse, InterAction+™ Cloud API applica vincoli di complessità analizzando la profondità e il costo computazionale delle query. Questo garantisce che query troppo complesse non compromettano le prestazioni.
- Profondità della Query: Limita la profondità massima delle query annidate per evitare strutture troppo ricorsive che potrebbero causare tempi di elaborazione eccessivi. Il limite attuale è di 25 livelli.
- Punteggio di Complessità: Il sistema calcola il punteggio totale di complessità di una query e rifiuta qualsiasi richiesta che superi la complessità massima consentita.
- Gestione delle Violazioni di Complessità: Se una richiesta supera il MaxDepth o la MaxComplexity definiti, l’API la rifiuterà con un messaggio di errore.
Best Practice
I Third-Party Client dovrebbero seguire le best practice per ottimizzare l’utilizzo dell’API restando entro i limiti di frequenza.
- Dovrebbero progettare query efficienti richiedendo solo i campi necessari ed evitando strutture troppo annidate per ridurre i tempi di elaborazione.
- Distribuire le richieste nel tempo invece di inviarle tutte in brevi intervalli.
- Implementare la cache per ridurre le richieste ridondanti e alleggerire il carico sull’API.
- Gestire correttamente le risposte di superamento dei limiti, gestendo gli errori 429 Troppe richieste e utilizzando le intestazioni di risposta per implementare meccanismi di backoff esponenziale o retry.